BEZBEDNOST INFORMACIONIH SISTEMA

VISOKA TEHNIČKA ŠKOLA KRAGUJEVAC ODSEK INFORMATIKA

PREDMET: BEZBEDNOST INFORMACIONIH SISTEMA

Bezbednost informacionih sistema

Sigurnost informacinih sistema

Standardi informacione sigurnosti

Odabrane tehnike zaštite Informacionih sistema

Predavač Mr Srđan Atanasijević, dipl.ing.inf

skripta Verzija 01.2009

Kragujevac, januar 2009.

Visoka tehnička škola Kragujevac ▼ Bezbednost informacionih sistema ▲ skripta

V01.2009

Page 2

Sadržaj: 1. Uvod ......................................................................................................................................................................7

1.1. Pojam sigurnosti informacija .......................................................................................................................7 1.1.1 Šta je to sigurnost informacija? ...............................................................................................................7 1.1.2 Potreba za integralnom zaštitom informacija ..........................................................................................8 1.1.3 Kako uspostaviti zahteve za sigurnost i zaštitu informacija..................................................................10

2. Međunardni standardi informacione bezbednosti................................................................................................11 2.1. Istorija ........................................................................................................................................................11 2.2. Upoznavanje sa terminima I definicijama informacione bezbednosti........................................................11

2.2.1 Standard ................................................................................................................................................11 2.2.2 Information Security Management System (ISMS) ..............................................................................12 2.2.3 International Organization for Standardization (ISO) ...........................................................................12

2.3. ISO/IEC 27000-serije.................................................................................................................................13 2.3.1 ISO/IEC 27001......................................................................................................................................14 2.3.2 ISO/IEC 27002......................................................................................................................................14

2.4. Standardizacija u oblasti upravljanja sigurnošću informacijama ...............................................................15 2.5. Poređenje kategorija ISO 17799:2005 i ISO 17799:2000 standarda..........................................................16

2.5.1 Politika bezbednosti ..............................................................................................................................16 2.5.2 Organizovanje informacione sigurnosti ................................................................................................16 2.5.3 Upravljanje resursima ...........................................................................................................................17 2.5.4 Sigurnost ljudskih resursa .....................................................................................................................17 2.5.5 Fizička zaštita........................................................................................................................................17 2.5.6 Upravljanje radom i komunikacijama ...................................................................................................17 2.5.7 Kontrola pristupa...................................................................................................................................18 2.5.8 Nabavka, razvoj i održavanje informacionih sistema............................................................................18 2.5.9 Upravljanje sigurnosnim incidentima ...................................................................................................18 2.5.10 Upravljanje kontinuitetom poslovanja ..................................................................................................18 2.5.11 Usaglašenost sa zakonskim i drugim propisima ...................................................................................19

2.6. Zaključna razmatranja................................................................................................................................19 3. Kriptografske tehnike za ostvarivanje zaštite IS..................................................................................................20

3.1. Motivacija ..................................................................................................................................................20 3.2. Istorijat .......................................................................................................................................................20 3.3. Kriptografija, osnovni pomovi ...................................................................................................................20 3.4. Osnovni kriptografski algoritmi.................................................................................................................21

3.4.1 Simetrični kriptografski algoritmi .........................................................................................................21 3.4.2 DES algoritam.......................................................................................................................................22 3.4.3 TWOFISH.............................................................................................................................................32

3.5. Asimetricni kriptografski aalgoritmi..........................................................................................................34 3.5.1 Kriptografija javnog ključa ...................................................................................................................34 3.5.2 Asimetrični algoritam............................................................................................................................34


V01.2009

Page 3

3.5.3 Algoritmi javnog ključa ........................................................................................................................36 3.5.4 RSA Algoritam......................................................................................................................................36 3.5.5 RSA digitalni potpis ..............................................................................................................................39 3.5.6 Nedostaci RSA algoritma......................................................................................................................40

3.6. Hibridni algoritmi: Kombinovana simetrična i asimetrična kriptografija ..................................................40 3.6.1 Šifrovanje i dešifrovanje dokumenata ...................................................................................................40 3.6.2 Hibridni sistem šifriranja – kriptosistem (Hybrid encryption sistem - Cryptosystem)..........................41 3.6.3 RSA šifrovanje u hibridnom kriptosistemu...........................................................................................44 3.6.4 Opis rada algoritma ...............................................................................................................................45 3.6.5 AES šifriranje........................................................................................................................................46 3.6.6 Hibridni algoritmi: zaključak ................................................................................................................48

3.7. Digitalni potpis, HASH..............................................................................................................................49 3.7.1 Uvod......................................................................................................................................................49 3.7.2 Osnovni principi rada digitalnog potpisa ..............................................................................................49 3.7.3 ULOGA POVERLJIVE STRANKE I POTPISIVANJE JAVNOG KLJUČA .....................................50 3.7.4 Funkcija za sažimanje – hash funkcija ..................................................................................................50 3.7.5 Digitalni potpis......................................................................................................................................50 3.7.6 Digitalni sertifikat .................................................................................................................................52 3.7.7 Digitalni potpis: zaključak ....................................................................................................................54

4. Ne kriptografske tehnike zaštite poverljivosti informacija ..................................................................................55 4.1. Mehanizmi kontrole pristupa : Tokeni.......................................................................................................55

4.1.1 Evolucija potrebe za autentifikacionim tokenima .................................................................................55 4.1.2 Password-cracking alati su takođe evoluirali ........................................................................................55 4.1.3 Jaka autentifikacija umanjuje rizik od slabih password-a .....................................................................55 4.1.4 Tokeni su dobri kandidati za jaku autentifikaciju .................................................................................56 4.1.5 Podela tokena na tipove.........................................................................................................................56 4.1.6 Probijanje tokena...................................................................................................................................57 4.1.7 Autentifikacija i uloga tokena ...............................................................................................................59

4.2. Administracija kontrole pristupa, domenska struktura...............................................................................64 4.2.1 Uvod......................................................................................................................................................64 4.2.2 Pretnje ...................................................................................................................................................70 4.2.3 Ko treba biti angažovan u sprovođenju politika odgovornosti? ............................................................70

4.3. Odbrana od zlonamernih programa, antivirusna politika ...........................................................................71 4.3.1 Definicija zlonamernih programa..........................................................................................................71 4.3.2 O Rootkits-ima ......................................................................................................................................71 4.3.3 Rootkits i rizici vezani za sigurnost ......................................................................................................74 4.3.4 Tehnike prevencije i zaštite od Rootkitaa .............................................................................................74 4.3.5 Patch management ................................................................................................................................75 4.3.6 Definisanje politike odgovora na incident.............................................................................................76 4.3.7 Zaključak...............................................................................................................................................78


V01.2009

Page 4

4.4. Elementi fizičke sigurnosti.........................................................................................................................79 4.4.1 pojam ostvarivanja fizičke sigurnosti objekata .....................................................................................79 4.4.2 Mantraps................................................................................................................................................79

4.5. Turnstiles ...................................................................................................................................................79 4.5.1 Zaključak...............................................................................................................................................82

4.6. Aspekti sigurnosti u projektovanju aplikacija............................................................................................82 4.6.1 Uvod u principe kompijuterske i mrežne organizacije, arhitekture i dizajna ........................................83 4.6.2 Osnove Web usluga i sigurnosti Web usluga.........................................................................................84 4.6.3 Security Assertion Markup Language...................................................................................................89 4.6.4 Standardi sigurnosti Web usluga ...........................................................................................................89 4.6.5 Preporuke implementacije sigurnosnih politika pri dizajnu aplikacija..................................................95 4.6.6 Zaključak...............................................................................................................................................96

5. Tehnike zaštite raačunarskih mreža.....................................................................................................................98 5.1. problematika zaštita računarskih mreža .....................................................................................................98 5.2. Zaštita savremenih visokopropusnih računarskih mreža............................................................................98

5.2.1 Performanse ..........................................................................................................................................98 5.2.2 Redundantnost.......................................................................................................................................98 5.2.3 Load balancing ......................................................................................................................................98 5.2.4 Multiemitovanje ....................................................................................................................................98 5.2.5 Više-protokolsko menjanje oznaka .......................................................................................................98

5.3. Mogućnosti enkripcije ...............................................................................................................................99 5.3.1 Link level enkripcija .............................................................................................................................99 5.3.2 Application level enkripcija ..................................................................................................................99 5.3.3 Network level enkripcija .......................................................................................................................99

5.4. Ograničenja IPSec enkripcije.....................................................................................................................99 5.5. Upravljanja distribucijom ključeva u mreži .............................................................................................100

6. Zaključak ...........................................................................................................................................................103 7. Literatura ...........................................................................................................................................................104 8. Dodatak .............................................................................................................................................................106

8.1. Slike .........................................................................................................................................................106 8.2. Tabele.......................................................................................................................................................107 8.3. Grafovi .....................................................................................................................................................107


V01.2009

Page 5

Predgovor prvom izdanju skripte za podršku nastavi predmeta “Bezbednost Informcionih sistema” na smeru Informatika,

Visoke tehničke škole u Kragujevcu.

Poštovani studenti, mlade kolege,

pokušali smo da u ovom materijalu objedinimo teme koje smo prošli tokom semestra kako na predavanjima, tako na laboratorijskim vežbama i seminarskom radovima.

Ovaj materijaal je osnov za polaganje završnog ispita, ali, nadam se i korsno stručno štivo koje će vam pomoći u praksi kada se na svojim radnim zadacima susretnete sa problematikom zaštite tajnosti informacija u poslovnim informacionim sistemima.

Komplet nastavnog materijala na predmetu “Bezbednost Informcionih sistema”:

1. Internet sajt: http://sites.google.com/site/BezbednostIS sa svojim sadržajima

a. Slajdovima sa predavanja,

b. Laboratorijskim vežbama,

c. Internet linkovima ka alatima koji su korišćeni kao primeri na vežbama I predavanjima

d. Standardima za bezbednost i informacionu sigurnost,

e. Odabranim seminarskim radovima studenata,

f. Agenda sa rasporedom termina predavanja, laboratoriskih vežbi, termina konsultacija i ispitnih rokova

2. Skripta sa materijalom koji je iznet na predavanjima i vežbama,

3. Softverski alati otvorenog koda sa demonstacijama kriptografskih algoritama:

a. www.crypTool.com

4. eMail adresa na koju možete postavljati pitanja i slati seminarske radove:

a. [email protected]


V01.2009

Page 6


V01.2009

Page 7

1. Uvod Savremeno poslovanje je danas nezamislivo bez primene informacionih tehnologija. Informacije postaju važan resurs

od koga zavisi opstanak i razvoj organizacije. Organizacije postaju sve otvorenije povezujući svoje informacione resurse sa kupcima, dobavljačima i ostalim komintentima. Ovo dovodi do pojave brojnih sigurnosnih pretnji kao što su računarske prevare, špijunaže, sabotaže, vandalizmi, požari, poplave i sl. Štete nanete organizacijama u obliku zloćudnog koda, računarskog hakerisanja i uskraćivanja usluga je sve prisutnija pojava. Bez obzira u kom obliku se čuvaju, informacije moraju da budu adekvatno zaštićene.

Da bi se osigurala adekvatna zaštita informacija svi korisnici moraju da budu upoznati sa konceptom i merama zaštite koje se zahtevaju. Zaštita informacija, očuvanje njihove poverljivosti, integriteta, odnosno celovitosti i raspoloživosti postaje od primarne važnosti. Sigurnost informacija je mnogo više od korišćenja odgovarajućih tehničkih rešenja koje nude savremene informacione tehnologije.

Oslanjajući se na koncept da je sigurnost informacija mnogo više od primene savremenih tehničkih rešenja koje nude informacione tehnologije, razvijeni svet (pre svih Velika Britanija kroz nacionalno telo za standardizaciju BSI) opredelio se za razvoj odgovarajućih standarda koji pokrivaju ovu oblast. Tako su sredinom devedesetih godina prošlog veka nastali prvi standardi BS 7799-1 i BS 7799-2. Razvoj ovih standarda je od 2000. godine preuzela Međunarodna organizacija za standardizaciju (ISO) zajedno sa Međunarodnom elektrotehničkom komisijom (IEC) kroz zajednički tehnički komitet (JTC1).

Da bi se razumela problematika koncepta sigurnosti informacija, trebalo bi da se pozabavimo sa nekoliko ključnih pitanja i to:

5. Šta se podrazumeva pod sigurnošću informacija?

6. Zašto je potrebna zaštita informacija?

7. Kako uspostaviti zahteve za sigurnost i zaštitu informacija?

1.1. Pojam sigurnosti informacija 1.1.1 Šta je to sigurnost informacija? Informacija: je podatak sa određenim značenjem, odnosno znanje koje se može preneti na bilo koji način (pismom,

audio, vizuelno, elektronski ili na neki drugi način).

Informacije mogu da budu:

• štampane ili napisane na papiru,

• odložene (memorisane) elektronski,

• prenesene poštom ili elektronskim putem,

• prikazane na korporacijskom web sajtu,

• verbalne – izgovorene u konverzaciji,

• znanje – veštine zaposlenih.

Sigurnost informacija se karakteriše kao čuvanje – Slika 2.3.:

• poverljivosti: osiguravanjem da informacije budu na raspolaganju samo onima koji su ovlašćeni da im pristupaju;

• integriteta: samozaštitom tačnosti i celovitosti informacija i metoda za obradu;

• raspoloživosti: osiguravanjem da ovlašćeni korisnici imaju pristup informacijama i odgovarajućim resursima kada im je potrebno.


V01.2009

Page 8

Slika 1.1 Model integralne informacione sigurnosti -CIA

Sigurnost informacija se ostvaruje uvođenjem pogodnog skupa kontrola, koje mogu biti politika, praksa, procedure, organizacione strukture i softverske funkcije. Ove kontrole treba uspostaviti kako bi se u organizaciji osiguralo ispunjavanje specifičnih ciljeva zaštite.

Sigurnosne mere uključuju mehanizme i procedure koje se implementiraju u cilju:

• odvraćanja,

• prevencije,

• detekcije i

• opravke,

od uticaja incidentnih događaja a koji deluju na poverljivost, celovitost i raspoloživost podataka i odgovarajućih servisa i resursa uključujući izveštavanje o sigurnosnim incidentima. Sigurnost informacija je ustvari proces upravljanja rizikom. Menadžment sigurnosti bi trebao da bude deo ukupnog menadžmenta rizicima a sigurnost informacija je samo jedan aspekt ukupne sigurnosti organizacije. Upravljanje rizicima mora da bude stalan, kontinuiran proces pošto su rizici sami po sebi promenjivi, a s druge strane stalno se generišu novi kao odraz promenjivog okruženja u kome organizacija ostvaruje svoju misiju. Ovo znači da je neophodno da se periodično preispituju rizici kao i pretnje i slabosti informacionih resursa. Ovo je upravo ono na čemu se bazira menadžment sistem za sigurnost informacija (Information Security Management System - ISMS).

1.1.2 Potreba za integralnom zaštitom informacija Informacije i njima pripadajući podaci, zatim procesi i sistemi (hardverski, softverski,mrežni itd.) koji se koriste za

njihovo generisanje, obradu, prenos, memorisanje kao i pristup predstavljaju važan deo poslovne imovine organizacije koju je potrebno prikladno zaštititi, ako se želi normalno poslovanje koje će obezbediti opstanak i razvoj. Ovaj zahtev postaje sve važniji zbog distribuirane poslovne okoline organizacije u kojoj su informacije izložene ranjivosti usled velikog broja pretnji (opasnosti) (slika 1.1).

Organizacije i njihovi informacioni sistemi suočavaju se sa pretnjama sigurnosti informacija iz širokog opsega izvora, uključujući prevare uz korišćenje računara, špijuniranje, sabotaže, vandalizme, terorizam, požare ili poplave. Izvori oštećenja kao što su računarski virusi, upadi u računare i onemogućavanje funkcionisanja računara postaju sve češći, ambiciozniji i usavršeniji.

Mnogi informacioni sistemi nisu projektovani tako da bi se štitili. Sigurnost koja se može ostvariti tehničkim sredstvima je ograničena, i mora se podržati odgovarajućim upravljanjem i procedurama. Utvrđivanje kontrola koje treba da se postave zahteva pažljivo planiranje i obraćanje pažnje na detalje. Da bi se upravljalo zaštitom informacija, kao minimum je potrebno učešće svih zaposlenih u organizaciji. Takođe mogu biti potrebni saveti specijalista izvan organizacije.

Kontrole za zaštitu informacija znatno su jeftinije i efikasnije ako se ugrade prilikom specificiranja zahteva u fazi projektovanja i razvoja informacionih sistema.

Nezavisno od prirode informacioni resursi (informacione vrednosti) (tabela 1.2.) mogu da imaju jednu ili više sledećih karakteristika:

• Prepoznati su na nivou organizacije kao entitet koji ima vrednost


V01.2009

Page 9

• Ne mogu lako da budu zamenjeni bez utroška resursa kao što su: novac, veštine zaposlenih, vreme itd.

• Čine identitet organizacije bez koga poslovanje organizacije može da bude ugroženo

Tabela 1.1 Kategorije informacionih resursa koje je neophodno zaštiti

Kategorija Informacionih resursa (vrednosti) Primeri:

Informacije Baze podataka i podaci, dokumenta vezana za sistem, korisnički priručnici, materijali za obuku, operativne i sistemske procedure

Softver Aplikativni i sistemski, alati za razvoj softvera

Fizički rezursi (hardver, kompjuterska oprema) Kompjuterski uređaji (procesori, monitori, modemi), kominikacioni uređaji (ruteri, svičevi, telefoni), magnetni medijumi (trake, diskovi), ostali tehnički uređaji (sistemi napajanja, hlađenja, itd.)

Usluge Usluge obrade podataka, komunikacione usluge

Osoblje Znanje i veštine osoblja (tehničkog, operativnog, finansijskog, itd.)

Zajednički uzrok oštećenja Ko je uzrokovao oštećenje Tipovi kompjuterskog kriminala

Graf 1.1 Uzroci i tipovi kompjuterskog kriminala

Pretnje informacionim resursima u nekoj organizaciji predstavljaju:

• Zaposleni

• Niska svest o potrebi zaštite informacija (korporativna kultura)

• Porast umreženosti i distribuirane obrade podataka

• Porast složenosti i efektivnosti hakerskih alata i virusa

• E-mail -ovi

• Požar, poplava, zemljotresi itd.

Osnovni ciljevi zaštite informacija u nekoj organizaciji je da se obezbedi:


V01.2009

Page 10

• kontinuitet poslovanja i

• minimizira rizke od potencijalnih šteta (havarija)

Ovo se postiže prevencijom incidentnih dogođaja i redukovanjem njihovog potencijalnog uticaja. Definisanje, implementacija, održavanje i unapređenje koncepta sigurnosti informacija može biti od presudne važnosti za ostvarivanje i održavanje konkurentnosti, dotoka novčanih sredstava i obezbeđenja profitabilnosti, kao i zadovoljenja zakonskih odredbi i osiguranja poslovnog ugleda organizacije. Sigurnost informacija je podjednako važna malim i velikim, kao i javnim i privatnim organizacijama. Povezanost javnih i privatnih računarskih mreža i deljenje informacija otežavaju kontrolu pristupa informacijama. U takvim uslovima oblici centralizovane kontrole nisu delotvorni. Odnosno, primena tehničkih rešenja, odgovarajuće opreme i proizvoda više nije dovoljna da bi osigurala odgovarajuće upravljanje sigurnošću informacija. Sigurnost informacija nije isključivi problem informacionih tehnologija (IT), već je to "poslovni" problem. Opšte je mišljenje da primenom odgovarajućih tehnologija se rešava samo jedan deo problema sigurnosti informacija. Danas se sigurnost informacija postiže primenom odgovarajućih kontrola (eng. control), koje se odnose na politiku sigurnosti, poslovne procese, procedure, strukturu organizacije i funkcije hardvera i softvera (sistemskog i aplikativnog). Kontrole važne za organizaciju sa zakonske tačke gledišta su:

a) zaštita informacija i tajnosti ličnih podataka;

b) čuvanje organizacionih izvještaja;

c) poštovanje prava intelektualnog vlasništva.

1.1.3 Kako uspostaviti zahteve za sigurnost i zaštitu informacija Osnovno je da organizacija definiše zahteve za sigurnost. Za to postoje tri glavna izvora.

• Prvi izvor se dobija ocenjivanjem rizika po organizaciju. Preko ocenjivanja rizika identifikuju se pretnje po imovinu, vrednuju se ranjivost i verovatnoća događanja i procenjuju se moguće posledice.

• Drugi izvor čine zakonski, statutarni i ugovorni zahtevi koje organizacija, njeni poslovni partneri, ugovarači i davaoci usluga moraju da ispune.

• Treći izvor čini poseban skup osnovnih postavki, ciljeva i zahteva za obradu informacija koje je organizacija razvila za podršku svojim poslovnim operacijama.


V01.2009

Page 11

2. Međunardni standardi informacione bezbednosti 2.1. Istorija

Standardizacija, kao sredstvo postizanja reda u određenoj oblasti, jeste disciplina koja je stara koliko i svet.

Tabela 1.1 prikaazuje genezu standarda kroz istoriju.

Tabela 2.1 Istorijat standarda

Istorijat Standarda

01. Kratak opis postupka izgradnje stubova u staroj Grčkoj, isklesan u kamenu – čuva se u Briselu

02. 410x200x120 mm dimenzije cigle (Egipćani)

03. Prvi industrijski standardi nastaju sa pojavom i razvojem serijske proizvodnje i industrije

04. 1843. godine Bavarske železnice naručuju seriju lokomotiva iz tri fabrike uz posebne zahteve

05. 1875. godine u Pruskoj su urađeni "Standardni nacrti za lokomotive, putničke i teretne vagone“, dve godine kasnije izrađene prve standardne lokomotive "tip 1b" za pruske železnice

06. Polovinom 19. veka se javljaju pokušaji planske standardizacije za veličinu cigle, a 1887. godine je propisan standard za kvalitet i način ispitivanja cementa

07. Ideja ujednačavanja obuhvata širok krug industrije u Evropi i Americi

08. Nastaju standardni proizvodi za razna područja, čak su mnoge fabrike počele da koriste iste delove kod različitih proizvoda (zavrtnji, matice,klinovi, čepovi,…)

09. Fabrike iste struke međusobno usklađuju interne standarde

10. Tadašnja velika preduzeća počinju osnivanje biroa za standardizaciju

11. Počinje osnivanje nacionalnih standardizacija, i to: Velika Britanija 1901.godine; Holandija 1916.godine; Nemačka 1917.godine, itd.

12. Prvu međunarodnu organizaciju za standardizaciju osnovali su elektrotehničari 1906. godine – Međunarodna elektrotehnička komisija IEC.

13. Povećanjem obima robne razmene i trgovine, javlja se problem postojanja različitih standarda za iste proizvode u raznim zemljama kao ozbiljna prepreka trgovini.

14. 1926.godine osnovan je Međunarodni savez za standardizaciju predhodnica današnje Međunarodne organizacije za standardizaciju ISO.

15. 80’ i 90’ – Američka vlada je izdala seriju knjiga Duginih boja (Rainbow series)

16. Pojedine države i njihovi sektori su objavljivali specifične standarde (zdravstvo, finansije..)

17. 1993. - BSI (British Standard Institute) Code of practice – Dobra praksa u sigurnosti

18. 1995. dorađen i postao je britanski standard 7799

19. 2000. korigovan 7799 je postao je PRVI međunarodni standard ISO 17799:2000

20. Trenutno je aktuelna grupa takozvanih 27K standarda – ISO 27000

2.2. Upoznavanje sa terminima I definicijama informacione bezbednosti 2.2.1 Standard • Standard je ono što se smatra osnovom za poređenje od strane vlasti ili je opšte priznato. //Vebsterov rečnik

• Standard je dokument koji ima za cilj da ujednači oblik, veličinu, kvalitet i način ispitivanja nekog materijala ili proizvoda. (Izdaje se u Zavodu za standardizaciju.) //Prosvetina enciklopedija

• Standard je dokument utvrđen konsenzusom i donet od priznatog tela kojim se za opštu i višekratnu upotrebu utvrđuju pravila, smernice ili karakteristike za aktivniosti ili njihove rezultate radi postizanja optimalnog nivoa uređenosti u određenoj oblasti. //SRPS ISO/IEC Uputstvo 2:2007 //Zakon o standardizaciji, 2005.godine


V01.2009

Page 12

• Standardizacija je aktivnost na utvrđivanju odredaba za opštu i višekratnu upotrebu, u odnosu na stvarne i potencijalne probleme, radi postizanja optimalnog nivoa uređenosti u određenoj oblasti. //Zakon o standardizaciji, 2005.godine

2.2.2 Information Security Management System (ISMS) ISMS, Information Security Management System, je kao što mu i samo ime kaže skup pravila koji se brine o

bezbednosti informacija.

Glavni koncept ISMS-a je za organizaciju da dizajnira , implementira i održava koherentne procese i sisteme za efikasno upravljanje dostupnih informacija i da na taj način osigurava poverljivost, integritet i dostupnost informacija imovine i smanjivanje rizika po bezbenošću informacija.

Sistem menadžmenta sigurnošću informacija (ISMS) je deo sveukupnog sistema menadžmenta, zasnovan na poslovnom riziku, sa ciljem da uspostavi, implementira, izvršava, nadzire, preispituje, održava i poboljšava sigurnost informacija (ISO 27001:2005). U standardu ISO 27001:2005 definisani su zahtevi koje organizacija mora da ispuni, kako bih dobila sertifikat za ISMS.

ISO/IES 27001 je zasnovan na tipičnom P-D-C-A ciklusu (Demingov krug) - Slika 1.1 .PDCA predstavlja koncept planiranja kao ciklus koji se bazira na kontinuiranom poboljšavanju.

Prvi korak predstavlja plan. Neko ima plan – zamisao za unapređenje proizvoda ili procesa. Ovaj korak vodi ka stvaranju plana za testiranje, poređenje, eksperiment. Plan izmene ili ispitivanja je ciljan za unapređenje kvaliteta ( proizvoda ili procesa ).

Drugi korak predstavlja rad na sprovođenju testa/ispitivanja, poređenja ili eksperimenta, po mogućnosti u maloj razmeri, u skladu s onim što je odlučeno u prvom koraku.

Treći korak predstavlja studiju rezultata. Potrebno je proučiti rezultate. Šta smo naučili? Šta nije išlo kako treba? Možda smo omanuli i u nečemu prevarili sami sebe, pa je potrebno startovati iznova.

Četvrti korak predstavlja akciju. Promenu usvajamo, ili je napuštamo ili ponovo prolazimo čitav krug, možda pod drugačijim uslovima sredine, sa drugim materijalima, drugim ljudima ili drugačijim pravilima. Za usvajanje promene, ili za njeno napuštanje, potrebno je predviđanje.

Slika 2.1 P-D-C-A ciklusu (Demingov krug)

2.2.3 International Organization for Standardization (ISO)

Međunarodna organizacija za standardizaciju nadaleko poznata kao ISO je međunarodni standard za utvrđivanje sadržaja sastavljen od predstavnika iz različitih nacionalnih standardnih organizacija.

Osnovana je 23.februara 1947, organizacija objavljuje širom sveta industrijsko vlasništvo i komercijalne standarde. Glavni štab je u Ženevi,Švajcarska.

Dok ISO definiše sam sebe kao nevladinu organizaciju, njegove sposobnosti da postavi standarde koji često postanu zakon, bilo putem ugovora ili nacionalnih standarda, čine ga snažnijim od većine nevladinih organizacija. U praksi ISO deluje kao udruženje ustanova sa jakim vezama u vladi.

Organizacijski logo je na dva oficijalna jezika, Engleskom i Francuskom, uključujući i reč ISO i uglavnom se pominje ovaj skarćeni oblik. ISO nije akronim ili inicijal za organizacijsko ime ni u jednom jeziku. Organizacija je radije prihvatila ISO zasnovano na Grckoj reči „isos” što znači jednako. Shvatajući da će organizacijski inicijali biti drugačiji na različitim jezicima, osnivači organizacije su izabrali ISO kao univerzalnu kratku formu svog imena. Ovo samo po sebi predstavlja glavni cilj organizacije: da se izjednači i standardizuje kroz sve kulture.


V01.2009

Page 13

Međunarodni standardi i druge publikacije:

• ISO-vi glavni produkti su MEÐUNARODNI STANDARDI.

• ISO još objavljuje i TEHNIČKE IZVEŠTAJE, TEHNIČKE SPECIFIKACIJE, JAVNO DOSTUPNE SPECIFIKACIJE, TEHNIČKU LISTU ŠTAMPARSKIH GREŠAKA I VODIČE.

Međunarodni standardi su definisani u formatu ISO/IEC.ASTM IS nnnnn(:yyyy)title , gde je :

• nnnnn broj standarda,

• yyyy godina publikacije,

• title opisuje predmet.

• IEC ili međunarodna elektrotehnička komisija je uključena ako su standardni rezultati iz rada ISO.IEC, JTC1

• ASTM se koristi za standarde proizvedene u saradnji sa ASTM internacional

• godina(yyyy) i IS se ne koriste za nekompletne ili neobjavljene standarde i mnogi pod istim okolnostima bivaju bez naslova objavljenog rada.

Tehnički izveštaji se izdaju kada tehnički komitet ili pododbor sakupi podatke različirih sadržaja koji se razlikuju od onih koji se obično izdaju kao međunarodne standardne norme, kao što su reference i objašnjenja. Imenovane konvencije za ove su iste kao i za standarde osim TR koji se stavlja umesto IS u imenu izveštaja.

Primeri:

• ISO/IEC TR 17799:2000 – Code of Practice for Information Security Management (praksa za informacijsku bezbednost upravljanja)

• ISO/TR 19033:2000 – TEHNIČKI PRODUKT DOKUMENTACIJE

Tehničke specifikacije mogu se proizvesti kada je predmet koji je u pitanju još uvek u razvoju ili je tamo zbog bilo kog drugog razloga gde se nalazi u budućnosti, ali ne i mogućnosti dogovora za objavljivanje međunarodnog standarda. Javno dostupne informacije mogu biti posredna specifikacija, objavljena pre razvoja punog međunarodnog standarda ili IEC-u može biti dvojni logo publikacije koja je objavljena u saradnji sa spoljnom organizacijom.

Obe su nazvane po konvenciji sličnoj tehničkom izveštaju, npr:

• ISO/TS 16952:2006 TEHNIČKI PRODUKT DOKUMENTA

• ISO/P1S 11154:2006 DRUMSKO VOZILO

ISO ponekad zadaje i tehničku listu štamparskih grešaka.To su i dopune postojećih standarda zato što su male tehničke greške, upotrebljive za poboljšanje ili da se produži primenljivost na ograničen način. Uopšteno, oni se objavljuju sa očekivanjem da će pogođeni standardi biti menjani ili povučeni na sledećem planiranom pregledu.

ISO VODIČI su meta-standardi koji pokrivaju pitanja vezana za međunarodnu standardizaciju. Imenovani su u formatu ISO.IEC GUIDE N:YYYY:TITLE

2.3. ISO/IEC 27000-serije ISO/IEC 27000-serije (još poznate i kao "ISMS porodica standarda" ili "ISO27K" - kraće) obuhvataju informacije o

bezbednosnim standardima koje su zajedno objavili međunarodna organizacija za standarde i međunarodna elektrotehnička komisija.

Serije nude najbolju praksu sa preporukama o informacijskom bezbednosnom sistemu, rizicima i kontroli u kontekstu celokupnog informacijskog bezbednosnog upravljackog sistema (ISMS), slično dizajnu za upravljanje sistema za osiguranje kvaliteta (ISO 9000 SERIJA) i zaštitu okoline (ISO 14000 SERIJA).

Serija obuhvata širok opseg, pokrivajući više od privatnosti, poverljivosti i IT-a ili bezbednosno-tehničkih problema. Primenljiva je na organizacije svih oblika i veličina. Sve organizacije su podstaknute da pristupe svojim informacijama o bezbednosnom riziku, koje primenjuju odgovarajuće informacije o bezbednosnim kontrolama u skladu sa svojim potrebama, koristeći smernice i sugestije koje su relevantne. S obzirom na dinamičnu prirodu informacione bezbednosti, ISMS koncept uključuje kontinuiranu povratnu informaciju i unapređuje delatnosti; sažeto od strane Demingovog kruga “planiraj-uradi-proveri-delaj” (plan-do-check-act) pristupa koji traži da se obrati pažnja promenama u pretnjama, ranjivosti ili udaru na informacionu bezbednosnih.

Trenutno 4 standarda u nizu su javno dostupni a još nekoliko je u izradi.


V01.2009

Page 14

2.3.1 ISO/IEC 27001 ISO/IEC 27001 je deo rastuće ISO/IEC 27000 serije standarda, to je informacijski sigurnosni sistem upravljanja

(ISMS), objavljen u oktobru 2005 od strane međunarodne organizacije za standardizaciju (ISO) i međunarodne elektrotehnicke komisije (IEC). Pun naziv je ISO/IEC 27001:2005 -informaciona tehnologija-sigurnosne tehnike-informacije o bezbednosti sigurnosne tehnike-informacije o bezbednosti upravljanja sistemima-zahtevi, ali uobicajeno je znan kao "ISO 27001".

Namenjen je da se koristi zajedno sa ISO/IEC 27002 (Kodeks prakse za informisanje uprave bezbednosti), koji izlistava listu sigurnosnih kontrolnih ciljeva i preporučuje niz specifičnih bezbednosnih kontrola. Organizacije koje sprovode ISMS u skladu sa najboljom praksom u ISO/IEC 27002 istovremeno zadovoljavaju i ISO/IEC 27001 ali sertifikacija je u potpunosti neobavezujuća ( osim ako nije ovlašćena od strane deoničara organizacije).

Sertifikacija: Organizacija može biti sertifikovana u skladu sa ISO/IEC 27001 od strane akreditovanih registara širom sveta.

Sertifikacija protiv bilo koje priznate nacionalne varijante ISO/IEC-a 27001 (npr. JIS Q 27001, japanska verzija) od strane akreditovanog sertifikacionog tela je funkcionalni ekvivalent za sertifikaciju ISO/IEC 27001. Sertifikacione revizije su uobičajeno sprovode od strane ISO/IEC 27001 glavnih revizora.

U nekim zemljama, upravna tela koja verifikuju usklađenost upravljanja sistemima i navode standarde zovu se “sertifikacioni upravni organi (ili tela)” u drugim zemljama poznati su kao “registarciona tela”, “procena i registracija tela”, “sertifikaciona/registraciona tela”,a ponekad i “registratori”.

ISO/IEC 27001 sertifikacija, kao i ostale ISO sertifikate upravljanja sistemima obično primenjuju tri stepena revizije procesa :

• PRVI: je “vrh tabele” pregled postojeće i kompletne dokumentacije kao što su organizaciona bezbednosna politika, izjava primenljivosti (SOA) i plan postupka rizika (RTP).

• DRUGI: je detaljna, duboka revizija koja uključuje testiranje postojanja i efektivnost informacionih sigurnosnih kontroli, navedenih u SOA i RTP, kao i njihovih pomoćnih dokumenata.

• TREĆI: je praćenje ponovne procene revizije da bi se potvrdilo da je prethodna sertifikaciona organizacija ostala u skladu sa standardima. Sertifikaciono održavanje uključuje periodične preglede i ponovne procene da bi se potvrdilo da ISMS nastavlja da deluje kao što je naznačeno i nameravano.

2.3.2 ISO/IEC 27002 ISO/IEC 27002 je deo rastuće porodice ISO/IEC ISMS standard, ISO/IEC 27000 serija je bezbednosna informacija

standarda objavljena od strane međunarodne organizacije za standardizaciju ISO i međunarodne elektrotehničke komisije IEC kao ISO/IEC 17799:2005 i naknadno ponovo numerisana kao ISO/IEC 27002:2005 u julu 2007 dovodeći ga u sklad sa drugim ISO/IEC 27000 serijama standard.

Pun naziv je informacijska tehnologija-bezbednosne tehnike-kod za praksu za informacijsku bezbednost upravljanja. Trenutni standard je revizija prvobitno objavljene verzije ISO/IEC 2000 koja je od reči do reči kopija Britanskog standard BS 7799-1:1999.

ISO/IEC 27002 pruža najbolju praksu preporukama o informaciji bezbednosnog upravljanja za korišćenje od strane tih koji su odgovorni za pokretanje, implementaciju ili održavanje informacijskog bezbednosnog upravljačkog sistema ISMS. Bezbednosna informacija je definisana unutar standarda u kontekstu C-I-A trijade.

• očuvanje tajnosti (osigurati da je informacija dostupna onima koji imaju ovlašćenje da pristupe),

• integritet (obezbeđuje tačnost i kompletnost informacije i obradivih podataka),

• dostupnost (osigurava da ovlašćeni korisnik ima pristup informaciji kada je potrebno)

Kratak pregled standarda:

1. procena rizika

2. bezbednosna politika - upravljački smer

3. organizacija bezbednosnih informacija - upravljanje bezbednosnim informacijama

4. upravljanje imovinom - inventar i klasifikacija imovinskih informacija

5. ljudska sigurnost - sigurnosni aspekti za radnike koji se pridružuju, sele ili napuštaju organizaciju


V01.2009

Page 15

6. fizička i okolišna sigurnost - zaštita računarskih postrojenja

7. komunikacije i operativni menadžment - upravljanje tehnički bezbednosnim kontrolama u sistemima i mreži

8. kontrole pristupa - ograničenje ulaska direktno u mreže, sisteme, aplikacije, funkcije i podatke

9. informacijski sistem nabavke, razvoja i održavanja - građenje bezbednosti u aplikacijama

10. informacijska bezbednost incidenta menadžmenta - učestvovanje, dobar odaziv na informacijsko bezbednosne upade

11. poslovni kontinuiteti upravljanja - štititi, održavati, obnavljati poslovno kritične procese i sisteme

12. saglasnost - osigurati pogađanje sa pravilima sa informacijsko bezbednosnom politikom, standardom, zakonom i propisima.

članice posmatrači predplatnički članovi ostale zemlje koje koriste ISO 3166-1 standard a koje nisu članice ISO-a

Slika 2.2 Mapa zemalja u kojima su primenjeni ISO standardi

2.4. Standardizacija u oblasti upravljanja sigurnošću informacijama Međunarodna organizacija za standardizaciju (ISO) i Međunarodna elektrotehnička komisija (IEC) su osnovali

zajednički tehnički komitet JTC1 u okviru koga radi stalni komitet SC27 (ISO/IEC JTC1/SC27 "IT Security Technique") koji se bavi razvojem standarda u oblasti sigurnosti IT sistema. Ovaj komitet je pokrenuo novu seriju standarda ISO/IEC 27000. Ovo je familija standarda o ISMS (menadžment sistema za sigurnost informacija) koja je planirana da se razvije u narednih 5-7 godina. Planirano je da ovu seriju (slika 3.1) čine:

• ISO/IEC 27000 ISMS - Osnove i rečnik pojmova

• ISO/IEC 27001 ISMS - Zahtevi

• ISO/IEC 27002 (ISO/IEC 17799 će postati posle 2007 godine) – Kodeks postupaka (dobra praksa) za upravljanje sigurnosti informacija

• ISO/IEC 27003 - ISMS Uputstvo za implementaciju

• ISO/IEC 27004 - Merenja u menadžmentu sigurnosti informacija

• ISO/IEC 27005 - Menadžment rizika sigurnosti informacija


V01.2009

Page 16

Slika 2.3 Razvoj standarda

Za sada su objavljena samo dva standarda iz ove serije. To si ISO/IEC 27001:2005 i ISO/IEC 17799:2005 (slika 2.4) Standard ISO/IEC 17799:2005 definiše kodeks dobre poslovne praksa u oblasti sigurnosti informacija. Čitav standard bazira se na jedanest sigurnosnih kategorija (poglavlja) koje pokrivaju sve aspekte sigurnosti informacija. Te kategorije su:

• Sigurnosna politika,

• Organizacija za sigurnost informacija,

• Upravljanje resursima,

• Sigurnost ljudskih resursa,

• Fizička sigurnost,

• Upravljanje komunikacijama i operacijama,

• Kontrola pristupa,

• Nabavka, razvoj i održavanje informacionih sistema,

• Upravljanje sigurnosnim incidentima,

• Upravljanje kontinuitetom poslovnih procesa,

• Usklađivanje sa zakonskim i drugim propisima.

2.5. Poređenje kategorija ISO 17799:2005 i ISO 17799:2000 standarda 2.5.1 Politika bezbednosti Definicija sigurnosne politike i kontrole u ovoj kategoriji nisu značajno promenjene u odnosu na verziju standarda iz

2000. godine. Jedina značajna razlika jeste u tome da nova verzija naglašava da sigurnosna politika može biti deo opšte politike organizacije, a ne mora nužno predstavljati poseban dokument.

2.5.2 Organizovanje informacione sigurnosti Kategorija Organizovanje informacione sigurnosti (u staroj verziji standarda Organizacijska sigurnost) doživela je

određene promene. Terminološki; umesto pojma treće strane (eng. third parties) iz stare verzije standarda sada se koristi pojam spoljni partneri (eng. external parties).

Takođe, nova verzija standarda kao posebne kontrole definiše kontakte sa vlastima (ili odgovornim osobama) i kontakte sa specijalizovanim interesnim (bezbednosnim i profesionalnim) grupama, za razliku od stare verzije gde je kontakt sa vlastima bio spomenut marginalno, dok kontakti sa specijalizovanim bezbednosnim grupama nisu bili uopšte spomenuti.

Standard je ustvari prihvatio već postojeće stavove da se sigurnost (i sigurnosni incidenti) ne prikrivaju pod svaku cenu, već je njihovo rešavanje u nekim slučajevima nužno kroz ovlašćene institucije, a komunikacija sa drugim stručnjacima kroz bezbednosne i profesionalne grupe i organizacije može uveliko pomoći pri rešavanju internih incidenata ili pri sprečavanju istih.

Takođe, sigurnosni cilj iz stare verzije standarda, koji se odnosio na obradu informacija kod spoljnih partnera (eng. outsourcing), u novoj verziji standarda uključen je u poglavlje Spoljni partneri, što je i logično.


V01.2009

Page 17

2.5.3 Upravljanje resursima Ova kategorija, iako joj je iz naziva izbačena reč klasifikacija (Klasifikacija i upravljanje resursima), i dalje obuhvata

iste ciljeve kao i u staroj verziji standarda.

Nova verzija u tom delu ipak donosi neke promene. Kao prvo, nova verzija naglašava da se moraju identifikovati SVI (informacioni) resursi, a nakon toga izdvojiti lista BITNIH informacionih resursa (stara verzija insistirala je samo na bitnim informacionim resursima). Takođe, još važnije, nova verzija prepoznaje i eksplicitno definiše nove kategorije resursa: ljude, njihovo znanje, stručnost i kvalifikacije kao i ugled i reputaciju organizacije. Konačno, dodate su nove kontrole Vlasništva nad resursima (eng. Ownership of assets) i Primerene upotrebe resursa (eng. Acceptable use of assets) kojima se eksplicitno definiše odgovornost vlasnika i korisnika resursa, što u prethodnoj verziji standarda nije bilo jasno definisano. Isto tako, nova verzija uvodi i pojam odgovorne osobe (eng. custodian) kojoj vlasnik resursa može delegirati određene odgovornosti.

2.5.4 Sigurnost ljudskih resursa Iako samo donekle promenjenog imena, ova kategorija značajno je promenjena. U prethodnoj verziji standarda toj

kategoriji (Zaštita od zaposlenih) bili su definisani ciljevi sigurnosti kod definisanja poslova (eng. Security in job definition and resourcing), obuci korisnika (eng. User training) i ponašanju u slučaju sigurnosnih incidenata (eng. Responding to security incidents).

Nova verzija standarda sigurnosne ciljeve i odgovarajuće kontrole definiše hronološki: Pre zapošljavanja (eng. Prior to employment), Tokom radnog odnosa (eng. During employment), Prestanak radnog odnosa (eng. Termination or change of employment). Neke sigurnosne kontrole preuzete su u manje izmenjenom obliku iz prethodne verzije standarda, a uz ciljeve koji se odnose na trajanje radnog odnosa i prestanak radnog odnosa, dodate su kontrole koje se odnose na odgovornost uprave, odgovornosti pri prestanku radnog odnosa, vraćanje resursa i uklanjanje prava pristupa.

Može se uočiti da je standard uvažio primere iz prakse, gde se pokazuje da pri prestanku ili prekidu radnog odnosa sigurnosni zahtevi uglavnom nisu sagledani u potpunosti. To se posebno odnosi na uklanjanje prava pristupa informacionim sistemima.

Cilj koji se odnosi na ponašanje u slučaju sigurnosnih incidenata u novoj verziji standarda izbačen je iz ove kategorije, pa se u izmenjenom obliku sada nalazi u novoj dodatoj kategoriji Upravljanje sigurnosnim incidentima.

2.5.5 Fizička zaštita Ova kategorija nije značajno izmenjena u odnosu na prethodnu verziju standarda. Može se uočiti da su neki ciljevi i

kontrole detaljnije i preciznije specificirani, dodata je nova kontrola koja eksplicitno definiše zaštitu od spoljnih i prirodnih pretnji (eng. Protecting against external and environmental threats), izbačen je cilj iz stare verzije standarda koji se odnosio na opšte zahteve (eng. General controls), koji je bio prilično neujednačen, sa tim da je deo kontrola ostao i dalje uključen u ovu kategoriju, a deo koji se odnosio na Bezbedno korišćenje radnog okruženja (eng. Clear desk and clear screen policy) prebačen je u kategoriju Kontrola pristupa, cilj Odgovornost korisnika (eng. User responsibilities), što je i mnogo logičnije.

2.5.6 Upravljanje radom i komunikacijama Upravljanje radom i komunikacijama najopsežnija je kategorija nove verzije standarda, a u odnosu na prethodnu

verziju standarda doživela je značajne promene. Od sigurnosnih ciljeva iz prethodne verzije standarda uz određene promene zadržani su sledeći:

Radne procedure i zaduženja (eng. Operational procedures and responsibilities) – kontrola koja se odnosila na upravljanje incidentima (eng. Incident management procedures) u staroj verziji standarda, u novoj verziji spada u kategoriju Upravljanje incidentima. Takođe, kontrola koja se odnosila na upravljanje delovima sistema koji održavaju spoljni partneri (eng. External facilities management) u novoj verziji standarda prepoznata je kao kompleksniji element bezbednosti, tako da predstavlja poseban sigurnosni cilj koji treba ispuniti.

Planiranje novih sistema (eng. System planning and acceptance) – ovaj cilj u novoj verziji nije značajnije izmijenjen u odnosu na staru verziju standarda.

Zaštita od zlonamernih programa (eng. Protection against malicious software) – ovaj cilj dopunjen je kontrolama koje se odnose na zaštitu od mobilnih programa, pa je i naslov u tom smislu dopunjen – Zaštita od zlonamernog i mobilnog koda (eng. Protection against malicious and mobile code). Standard je ovde uvažio činjenicu da je korišćenje mobilnog koda (ActiveX, Java i slične tehnologije) vrlo rašireno u legitimne, ali i zlonamerne svrhe.

Zaštita mrežne infrastrukture (eng. Network management – u staroj verziji, Network security management u novoj verziji) – ovaj cilj izmenjen je utoliko što je dodata nova kontrola koja eksplicitno definiše i zaštitu mrežnih servisa.

Sigurnost i rukovanje medijima (eng. Media handling) – ovaj cilj nije značajnije izmenjen u odnosu na staru verziju standarda.


V01.2009

Page 18

Osim navedenih ciljeva iz prethodne verzije standarda, novi standard definiše ciljeve koje stari standard nije poznavao u tom obliku:

Upravljanje spoljnim resursima (eng. External facilities management) – kako je već spomenuto predstavlja u novom standardu, zbog uočene važnosti, poseban cilj, za razliku od stare verzije standarda gdje je bio definisan samo kao kontrola.

Izrada rezervnih kopija (eng. Back-up) – predstavlja cilj koji je preciznije definisan u odnosu na cilj iz prethodnog standarda Održavanje reda u organizaciji (eng. Housekeeping), a koji je osim kontrola za izradu rezervnih kopija sadržao i elemente vezane za beleženje informacija koji u novoj verziji predstavljaju poseban cilj (Nadgledanje sistema).

Razmena informacija (eng. Exchange of information) – iako ovaj cilj ima vrlo sličan naziv kao i u staroj verziji standarda: Razmena informacija i programske podrške (eng. Exchange of information and software), konceptualno je prilično promenjen tako da su u novoj verziji standarda predložene kontrole puno konzistentnije sa obzirom na cilj.

Elektronsko poslovanje (eng. Electronic commerce services) – novi standard uočio je važnost sigurnosti ovog aspekta poslovanja, pa ga navodi kao poseban cilj, za razliku od stare verzije koja je aspekte elektronskog poslovanja prilično šturo definisala kroz posebnu sigurnosnu kontrolu vezanu uz Razmenu informacija i programske podrške.

Nadgledanje sistema (eng. Monitoring) – ovo poglavlje objedinjuje kontrole koje su se odnosile na različite ciljeve iz stare verzije standarda. Na taj način izbegnuto je pojavljivanje sličnih elemenata u različitim delovima dokumenta (Upravljanje radom i komunikacijama, Kontrola pristupa), čime je osigurana veća koherentnost.

2.5.7 Kontrola pristupa Ova kategorija logički nije značajno izmenjena u odnosu na staru verziju standarda. Jedina značajna promena jeste da

cilj Nadgledanje pristupa i korišćenja sistema (eng. Monitoring system access and use) u novoj verziji standarda više nije deo kategorije Kontrola pristupa, već je dopunjen sa nekim kontrolama iz drugih kategorija, već je deo kategorije Upravljanje radom i komunikacijama.

Takođe, u cilj Obaveze korisnika dodata je kontrola Bezbedno korišćenje radnog okruženja (eng. Clear desk and clear screen policy), koja je u staroj verziji standarda bila deo Opštih zahteva kategorije Fizička zaštita.

Ostali ciljevi iz ove kategorije ostali su isti, dok su kontrole izmenjene i osavremenjene u tolikoj meri da bolje opisuju načine zaštite modernih sistema.

2.5.8 Nabavka, razvoj i održavanje informacionih sistema Kod ove kategorije promenjen je naziv, tako da sada preciznije identifikuje na šta se odnosi (u staroj verziji standarda

Razvoj i održavanje sistema). Iz stare verzije standarda preuzeti su svi ciljevi, čije kontrole su u određenoj meri dopunjene i osavremenjene. Najznačajnije promene napravljene su kod cilja Kriptografske kontrole (eng. Cryptographic controls) gde su preporuke za implementaciju preciznije nego u staroj verziji standarda i referenciraju druge spoljne izvore i standarde (ISO/IEC JTC1 SC27, IEEE P1363, OECD Guidelines on Cryptography, ISO/IEC 9796, ISO/IEC 14888).

Takođe, nova verzija standarda definiše cilj Upravljanje tehničkim ranjivostima (eng. Technical vulnerability management) koji nije postojao u staroj verziji standarda, a u praktičnom održavanju sigurnosti današnjih sistema je nezaobilazan.

2.5.9 Upravljanje sigurnosnim incidentima Upravljanje sigurnosnim incidentima (eng. Information security incident management) je nova kategorija koja se

pojavljuje u ISO 17799:2005 standardu. Kategorija definiše dva cilja:

1. Prijavljivanje sigurnosnih incidenata i ranjivosti (eng. Reporting information security events and weaknesses) i

2. Upravljanje sigurnosnim incidentima i unapređenjem sigurnosti (eng. Management of information security incidents and improvements).

Ova kategorija predstavlja skup ciljeva i sigurnosnih kontrola, od kojih je većina postojala i u prethodnoj verziji standarda no, međutim, te su kontrole bile definisane u različitim kategorijama i ciljevima, (Odgovornost korisnika – Prijavljivanje sigurnosnih incidenata i nepravilnosti u radu, Upravljanje radom i komunikacijama – Radne procedure i zaduženja, Usaglašenost sa zakonskim i drugim propisima – Usaglašenost sa zakonskom regulativom).

Standard je uočio da je upravljanje sigurnosnim incidentima jedinstven proces, pa ga je na taj način i definisao, što predstavlja znatno unapređenje u odnosu na staru verziju standarda.

2.5.10 Upravljanje kontinuitetom poslovanja Kategorija upravljanja kontinuitetom poslovanja strukturalno gotovo da i nije promenjena. U načelu kontrole koje

nova verzija standarda predlaže gotovo da su identične kontrolama iz prethodne verzije. Sintaksa koja se koristi u novoj verziji


V01.2009

Page 19

standarda ipak je preciznija, a iz definicije sigurnosnog cilja koje se kontrole iz ove kategorije moraju ispuniti može se uočiti da je sigurnost ipak samo deo opštijeg procesa upravljanja kontinuitetom poslovnih procesa, dok je prethodna verzija implicirala da je kompletno upravljanje kontinuitetom poslovnih procesa deo informacione sigurnosti.

Može se zaključiti da je to posledica višegodišnjih trendova kroz koje se informaciona sigurnost više ne posmatra isključivo kao deo IT-a, već se sve više i više smatra integralnim delom u ukupnom odvijanju poslovnih procesa i poslovanju.

2.5.11 Usaglašenost sa zakonskim i drugim propisima Ova sigurnosna kategorija smisleno gotovo da i nije promenjena. Kontrole su iste kao i u ranijoj verziji standarda.

Kontrola prikupljanje dokaza, koja je izbačena u odnosu na verziju standarda iz 2000. godine je u novoj verziji standarda deo kategorije Upravljanje sigurnosnim događajima.

2.6. Zaključna razmatranja Svaka od navedenih sigurnosnih kategorija definiše sigurnosne ciljeve kao i kontrole koje je potrebno sprovesti da bi

se ispunili ti ciljevi. Važno je napomenuti da se kontrole definišu kao: način upravljanja rizicima, što podrazumeva politike, procedure, uputstva, organizacione strukture koje mogu da budu administrativne, tehničke, upravljačke ili pravne.

Paralelno sa ovim standardom razvijan je standard (ISO/IEC 27001) koji definiše zahteve koje menadžment sistema za sigurnost informacija mora da zadovolji i po kome se sprovodi sertifikacija ISMS-a ako se to zahteva. Ovi zahtevi baziraju se na ciljevima i kontrolama (dobroj poslovnoj praksi) koje su definisane u standardu ISO/IEC 17799.

Ceo koncept sigurnosti informacija koji je definisan u standardima ISO/IEC 27001 i ISO/IEC 17799 bazira se na konceptu upravljanja (menadžmentu) rizicima. Ocena rizika je definisana kao ocena pretnji informacijama (pretnje koje dovode do povrede poverljivosti, integriteta i raspoloživosti informacija) njihovog uticaja na informacije i na ranjivost (slabost) informacija i informacionih sistema kao i verovatnoće njihove pojave.

Upravljanje (menadžment) rizikom je definisano kao proces identifikacije, kontrole i umanjivanja ili eliminacije sigurnosnih rizika koji mogu da utiču na informacije i informacione sisteme, a koji mora da bude finansijski pravdan.

▲▼▲

Savremeni trendovi koji se ogledaju u globalizaciji tržišta i uniformnosti odnosno težnji za standardizacijom aktivnosti u oblasti sistema menadžmenta, nameće potrebu i obavezu da se i u našim uslovima i okruženjima sprovedu koraci u pravcu istraživanja, implementacije, održavanja i unapređenja sistema menadžmenta.

U pravcu ostvarivanja efektivnih i efikasnih sistema za menadžment u oblastima IT usluga neophodno je koristiti model ISO 20000 i zahteve koje su u njemu specificirani. Time se ostvaruje konkurentska prednost u odnosu na organizacije koje ne primenjuju ove norme.

U vremenu izrazitog rasta količine informacija i znanja u organizacijama i u njihovoj komunikaciji sa korisnicima, za potrebe bezbednosti informacija i potrebe sticanja korisničkog poverenja, neophodno je koristiti zahteve modela ISO 27001.

Time se stvara sistem koji je fokusiran na kontinualna poboljšavanja i smanjenje troškova i eliminisanje uzročnika grešaka u sistemu. Zajedničkim delovanjem ISO 20000 i ISO 27001 uz podršku modela ISO 9001 ostvaruje se sistem za bezbednost informacija sa punim poverenjem i usaglašenošću sa pravnim normama okruženja.


V01.2009

Page 20

3. Kriptografske tehnike za ostvarivanje zaštite IS 3.1. Motivacija

Sigurnost računarskih sistema postaje značajna, jer korisnici n koristi sve više informacija u svetu računara. U takvom sistemu postoji i sve veća opasnost od neovlašćene upotrebe informacija, podmetanja krivih informacija ili uništavanja informacija. U računarskim sistemima informacije se prenose raznovrsnim otvorenim i nesigurnim komunikacijskim putevima. Pristup do tih puteva ne može se fizički zaštititi pa svaki neprijateljski nastrojen napadač može narušiti sigurnost sistema. Zbog toga zaštitni komunikacijski mehanizmi nad nesigurnim komunikacijskim kanalom postaju najvažniji oblik ostvarenja sigurnosti. Pokazuje se da je najdelotvornija zaštita poruka njihovo kriptovanje.

Kako današnji računarski sistemi teže što većoj otvorenosti, tako se uvode standardi u svim područjima korišćenja računara. Prema tome, samo je bilo pitanje vremena kada će doći do standarda u kriptovanju, što se ostvarilo 1976. godine pojavom DES-a (engl. Data Encryption Standard). S vremenom je DES prestao zadovoljavati teške kriterijume pa je i zamenjen 1998. godine novim standardom, AES-om (engl. Advanced Encryption Standard) za koji se veruje da je dovoljno siguran.

3.2. Istorijat Krajem 60-tih i početkom 70-tih godina 20. veka, razvojem finansijskih transakcija, kriptografija postaje zanimljiva

sve većem broju potencijalnih korisnika. Do tada je glavna primena kriptografije bila u vojne i diplomatske svrhe, pa je bilo normalno da svaka država (ili čak svaka zainteresovana državna organizacija) koristi svoju šifru za koju je verovala da je najbolja. No, tada se pojavila potreba za šifrom koju će moći koristiti korisnici širom sveta, i u koju će svi oni moći imati poverenje - dakle, pojavila se potreba uvođenja standarda u kriptografiji.

Godine 1972. američka Nacionalna uprava za standarde (NBS - National Bureau of Standards) inicirala je program za zaštitu računarskih i komunikacijskih podataka. Jedan od ciljeva bio je razvijanje jednog standardnog programa za kriptovanje tzv. algoritma. Godine 1973. NSB je raspisao javni konkurs za takav program koji je trebalo da zadovolji sledeće zahteve:

• visoki stepen sigurnosti

• potpuna specifikacija i lako razumevanje algoritma

• sigurnost leži u ključu, a ne u tajnosti algoritma

• dostupnost svim korisnicima

• prilagodljivost upotrebi u različitim primenama

• ekonomičnost implementacije u elektroničkim uređajima

• efikasnost

• mogućnost provere

• mogućnost izvoza (zbog američkih zakona).

Na tom konkursu nijedan predlog nije zadovoljavao sve ove zahteve. Međutim, na ponovljenom konkursu sledeće godine pristigao je predlog algoritma koji je razvio IBM-ov tim kriptografa. Algoritam je zasnovan na tzv. Feistelovoj šifri. Gotovo svi simetrični blokovni algoritmi koji su danas u upotrebi koriste ideju koju je uveo Horst Feistel 1973. godine. Jedna od glavnih ideja je naizmenična upotreba supstitucije i trasnpozicije kroz više iteracija.

Predloženi algoritam je nakon nekih izmena, u kojima je učestvovala i američka vladina ustanova zadužena za sigurnost (NSA - National Security Agency), prihvaćen kao standard 1976. godine i dobio je ime Data Encryption Standard (DES).

3.3. Kriptografija, osnovni pomovi Kriptografija je nauka o tajnom pisanju (zapisivanju), i bavi se metodama očuvanja tajnosti informacija.

Kriptografski algoritam transformiše čitljiv tekst P (od plaintext) u nečitljiv tekst C (od ciphertext). Kriptoanaliza je, obrnuto, nauka o dobijanju čitljivog teksta P (ili ključeva, ...), tako da napad na privatnost kriptovanih podataka zapravo predstavlja pokušaj kriptoanalize.


V01.2009

Page 21

Kriptologija je nauka koja obuhvata i kriptografiju i kriptoanalizu.

Osnovni elementi kriptografske metode za zaštitu su:

• šifrovanje – transformacija čitljivog teksta u nečitljiv oblik,

• dešifrovanje – postupak vraćanja šifrovanog teksta u čitljiv oblik,

• ključ – početna vrednost algoritma kojim se vrši šifrovanje; može biti reč, broj ili fraza,

• plaintext – generalno, informacija koju želimo očuvati privatnom, i

• ciphertext – kriptovan tekst, nečitljiv, onaj koji treba dekriptovati

Namena kriptografije je da zaštiti memorisanu informaciju čak i u slučaju da neko neovlašćen pristupi podacima. Kriptografski algoritmi predstavljaju matematičke funkcije koje se koriste za šifrovanje i/ili dešifrovanje, a mogu biti:

• Ograničeni algoritmi: bezbednost se zasniva na tajnosti algoritma, i

• Algoritmi zasnovani na ključu: bezbednost se zasniva na ključevima, a ne na detaljima algoritma koji se može publikovati i analizirati (algoritam je javno poznat, a ključ se čuva tajnim).

Moderna kriptografija koristi algoritme zasnovane na ključu, zbog njihovih praktičnih prednosti u odnosu na ograničene algoritme. Konkretan skup koji se sastoji iz kriptografskih algoritama, protokola koji omogućuju njihov rad i svih mogućih ključeva naziva se kriptosistem.

3.4. Osnovni kriptografski algoritmi Nekada, pre nego što su računari ušli u široku upotrebu, tj. pre nego su se dovoljno razvili, većina kriptografskih

metoda šifriranja se bazirala na tajnosti šifre. No, tako bazirani algoritmi su se pokazali dosta nepouzdani, te su se morale pronaći neke druge metode šifriranja. Današnje metode šifriranja zasnivaju se na upotrebi ključa. Ključ je najvažniji deo u pravilnom enkriptiranju i dekriptiranju poruka.

Upravo zavisno od načina korišćenja ključa, razvile su se dve klase algoritama. Jedna je simetrična, a druga asimetrična klasa. Drugim riječima, postoje simetrični algoritmi kriptovanja i asimetrični algoritmi kriptovanja. Osnovna razlika je u tome da simetrični algoritmi koriste isti ključ za enkripciju i dekripciju neke poruke (shared secret key cryptography), ili se ključ za dekripciju može lako proizvesti iz originalnog ključa za enkripciju; dok asimetrični algoritmi koriste različite ključeve za enkripciju i dekripciju iste, od kojih je jedan javni i poznat svima, a drugi tajni i poznat samo jednom od učesnika u komunikaciji (public key cryptography).

3.4.1 Simetrični kriptografski algoritmi Kod simetrične kriptografije postupak enkripcije i dekripcije zasniva se na dve matematički srodne funkcije:

Slika 3.1 Simetrična kriptografija

Enkripciona funkcija E, na osnovu ključa k i ulazne poruke m, kreira zaštićenu poruku c. Dekripciona funkcija D, na osnovu istog ključa k i zaštićene poruke c, restaurira originalnu poruku m.

Osnovna prednost ovog načina kriptografije u odnosu na asimetričnu kriptografiju jeste ta što je manje računski intenzivna, tako da se veće količine podataka brže enkriptuju/dekriptuju. Velika je mana činjenica da moramo pronaći bezbedan način za distribuciju tajnog ključa, tj. neophodno je osigurati bezbedan kanal za razmenu ključeva između zainteresovanih strana. Ukoliko bismo već imali tako besprekoran siguran kanal, kriptografija nam ne bi bila ni potrebna: jednostavno bi poslali same podatke preko takvog kanala. Takođe, u današnjim intenzivnim razmenama podataka preko


V01.2009

Page 22

Interneta, izuzetno je nepraktično generisati ogroman broj ključeva koji su neophodni za komunikaciju: kad god komuniciramo sa nekom drugom stranom, moramo imati ključ koji je jedinstven samo za komunikaciju sa dotičnim klijentom/serverom.

Najpoznatiji simetrični enkripcioni algoritmi:

• DES (Data Encryption Standard) – ključ je dužine 56 bita,

• Triple DES, DESX, GDES, RDES – ključ je dužine 168 bita,

• (Rivest) RC2, RC4, RC5, RC6 – promenljiva dužina ključa do 2048 bita,

• IDEA (International Data Encryption Algorithm) – osnovni algoritam za PGP (Pretty Good Privacy) – ključ je duž ine 128 bita,

• Blowfish – promenljiva duž ina ključa do 448 bita,

• AES (Advanced Encryption Standard) - radi sa blokovima od po 128 bita i koristi ključeve duž ine 128, 192 i 256 bita.

• Rijndael - kriptografski postupak se izvršava nad blokovima od 128, 192 ili 256 bita, a tolika može biti i dužina ključeva. Tako se može definisati 2128, 2192 ili 2256 ključeva.

3.4.2 DES algoritam DES algoritam je najčešće korišćen algoritam za kriptovanje na svetu. Dugo godina je bio sinonim za sigurno

šifriranje, a donedavno i standardni algoritam za enkripciju.

Odlike:

• nastao od LUCIFER-a (NBS,IBM,NSA)

• enkriptuje blok veličine 64 bita

• koristi ključ dužine 64 bita (56 efektivno)

• varijabilan broj rundi (zavisi od dužine ključa i dužine bloka)

• koristi 16 podključa dužine 48 bita

• koriste se Feistel runde.

Opis algoritma DES-a DES šifrira otvoreni tekst dužine 64 bita, koristeći ključ K dužine 56 bitova, tako se dobija šifrat koji ponovo ima 64

bita.

Algoritam se sastoji od 3 etape:

1. Za dati otvoreni tekst x, permutovanjem pomoću fiksne inicijalne permutacije IP dobije se x0. Zapišemo x0 = IP(x) u obliku x0 = L0R0, gde L0 sadrži prva (leva) 32 bita, a R0 zadnja (desna) 32 bita od x0.

2. Određena funkcija se 16 puta iterira. Računamo Li Ri, 1 ≤ i ≤ 16, po sledećem pravilu:

Li = Ri -1

Ri = Li -1 f (Ri -1, Ki),

gde označava operaciju "ekskluzivno ili" (XOR). Funkciju f ćemo opisati kasnije, a K1, K2, ... , K16 su nizovi bitova dužine 48, koji se dobijaju kao permutacije nekih bitova iz K.

3. Primenimo inverznu permutaciju IP-1 na R16L16 i tako dobijamo šifrat y. Dakle,

y = IP-1(R16L16).

Uočimo inverzni poredak od L16 i R16.


V01.2009

Page 23

Slika 3.2 Inverzni poredak od L16 i R16

Funkcija f za prvi argument ima niz bitova A dužine 32, a za drugi argument ima niz bitova J dužine 48. Kao rezultat se dobija niz bitova dužine 32. Funkcija se računa u sledeća 4 koraka:

1. Prvi argument A se "proširi" do niza dužine 48 u skladu s fiksnom funkcijom proširenja E. Niz E(A) se sastoji od 32 bita iz A, permutiranih na određeni način, s time da se 16 bitova pojavi dvaput.

1. Izračunamo E(A) J i rezultat zapišemo kao spoj od osam 6-bitnih nizova

B = B1B2B3B4B5B6B7B8.

2. Sledeći korak koristi 8 tzv. S-kutija (supstitucijskih kutija) S1, ... , S8. Svaki Si je fiksna 4 × 16 matrica čiji su elementi celi brojevi između 0 i 15. Za dati niz bitova dužine 6, recimo Bj = b1b2b3b4b5b6, računamo Sj (Bj) na sledeći način. Dva bita b1b6 određuju binarni zapis reda r od Sj (r = 0,1,2,3), a četiri bita b2b3b4b5 određuju binarni zapis kolone c od Sj (c = 0,1,2,...,15). Sada je Sj (Bj) po definiciji jednako Sj (r,c), zapisano kao binarni broj dužine 4. Na ovaj način izračunamo Cj = Sj (Bj), j = 1,2,...,8.

3. Niz bitova C1C2C3C4C5C6C7C8 dužine 32 se permutira pomoću fiksne završne permutacije P. Tako se dobije P(C), što je po definiciji upravo f(A,J).

Slika 3.3 S-kutija

Konačno, treba opisati računanje tablice ključeva K1, K2, ... , K16 iz ključa K.


V01.2009

Page 24

Ključ K se sastoji od 64 bita, od kojih 56 predstavlja ključ, a preostalih 8 bitova služe za testiranje pariteta. Bitovi na pozicijama 8, 16, ... , 64 su definisani tako da svaki bajt (8 bitova) sadrži neparan broj jedinica. Ovi bitovi se ignorišu kod računanja tablice ključeva.

1. Za dati 64-bitni ključ K, ignorišemo paritetne bitove, te permutujemo preostale bitove pomoću fiksne permutacije PC1. Zapišemo PC1(K) = C0D0, gde C0 sadrži prvih 28, a D0 zadnjih 28 bitova od PC1(K).

2. Za i = 1, 2, ... , 16 računamo:

Ci = LSi (Ci -1), Di = LSi (Di -1),

Ki = PC2(Ci Di).

LSi predstavlja ciklički pomak ulevo za 1 ili 2 pozicije, u zavisnosti od i. Ako je i = 1, 2, 9 ili 16, onda je pomak za jednu poziciju, a inače je pomak za dve pozicije. PC2 je još jedna fiksna permutacija.

Ovim je u potpunosti opisan postupak šifriranja.

Dešifriranje koristi isti algoritam kao šifriranje. Krenemo od šifrata y, ali koristimo tablicu ključeva u obrnutom redosledu: K16, K15, ... , K1. Kao rezultat dobijamo otvoreni tekst x.

Uverimo se da ovako definisana funkcija dešifriranja dK zaista ima traženo svojstvo da je dK(y) = x. Podsetimo se da smo y dobili kao y = IP-1(R16L16). Zato se primenom inicijalne permutacije na y dobije y0 = R16L16. Nakon prve runde

dešifriranja, leva polovina postaje L16 = R15, a desna R16 f(L16,K16). Ali, iz zadnje runde šifriranja znamo da važi:

R16 = L15 f(R15,K16) = L15 f(L16,K16).

Zato je R16 f(L16,K16) = L15. Znači, nakon jedne runde dešifriranja dobijamo R15L15. Nastavljajući taj postupak, nakon svake sledeće rudne dešifriranja dobijaćemo redom: R14L14, R13L13 ..., R1L1 i nakon zadnje runde R0L0. Preostaje zameniti poredak leve i desne polovine i primeniti IP-1. Dakle, na kraju postupka dešifriranja dobijamo IP-1(L0R0), a to je upravo otvoreni tekst x, što je i trebalo dokazati.

Vidimo da razlog za zamenu leve i desne polovine pre primene permutacije IP-1 leži upravo u želji da se za dešifriranje može koristiti isti algoritam kao za šifriranje.

Svojstva DES-a

Uočimo da su sve operacije u DES-u linearne (setimo se da je zapravo sabiranje u Z2), s izuzetkom S-kutija. Već smo na primeru Hillove šifre videli da je kod linearnih algoritama kriptoanaliza napadom "poznati otvoreni tekst" vrlo jednostavna. Zato su S-kutije izuzetno značajne za sigurnost DES-a. Od objave algoritma, pa sve do danas, S-kutije su obavijene tajnovitošću. Videćemo da će se kod naslednika DES-a upravo taj deo promeniti: S-kutije će biti generisane eksplicitno navedenim algoritmom.

Kod DES-a znamo samo neke kriterijume koji su korišćeni u dizajniranju S-kutija:

1. Svaki red u svakoj S-kutiji je permutacija brojeva od 0 do 15.

2. Nijedna S-kutija nije linearna funkcija ulaznih podataka.

3. Promena jednog bita u ulaznom podatku kod primene S-kutije ima za posledicu promenu barem 2 bita u izlaznom podatku.

4. Za svaku S-kutiju i svaki ulazni podatak x (niz bitova dužine 6), S(x) i S(x 001100) razlikuju se za barem 2 bita.

5. Za svaku S-kutiju, svaki ulazni podatak x i sve e, f {0,1} vredi S(x) ≠ S(x 11ef00).

Kriterijumi za permutaciju P bili su sledeći:

1. Četiri izlazna bita iz svake S-kutije utiču (čine ulazne podatke) na šest različitih S-kutija u idućoj rundi, a nijedna dva ne utiču na istu S-kutiju.

2. Četiri izlazna bita iz svake S-kutije u i-toj rundi su distribuirani tako da dva od njih utiču na središnje bitove u (i+1)-voj rundi, a dva na krajnje bitove (dva krajnje leva i dva krajnje desna od 6 bitova u ulaznom podatku).


V01.2009

Page 25

3. Za dve S-kutije Sj i Sk vredi da ako neki izlazni bit od Sj utiče na neki središnji bit od Sk u idućoj rundi, onda nijedan izlazni bit od Sk ne utiče na središnje bitove od Sj. Za j = k ovo povlači da izlazni bitovi od Sj ne utiču na središnje bitove od Sj.

Ovi kriterijumi imaju za zadatak povećati tzv. difuziju algoritma, tj. postići da na svaki bit šifrata utiče što više bitova otvorenog teksta. Oni takođe otežavaju i tzv. diferencijalnu kriptoanalizu.

Poželjno svojstvo svakog algoritma jeste da mala promena bilo otvorenog teksta bilo ključa dovodi do značajne promene u šifratu. Posebno, promena jednog bita otvorenog teksta ili jednog bita ključa trebalo bi uticati na mnogo bitova šifrata. Ako je promena mala, to može značajno smanjiti broj otvorenih tekstova ili ključeva koje treba ispitati.

Algoritam DES ima gore opisano svojstvo koje se ponekad naziva i "efekt lavine". Ilustrovaćemo to sa dva primera (preuzetim iz knjige [Stinson: Cryptography. Theory and Practice]).

Primer 1: Otvoreni tekstovi (zapisani heksadecimalno)

0000000000000000 i 1000000000000000

šifrirani su pomoću ključa (takođe zapisanog heksadecimalno s uključenim paritetnim bitovima)

029749C438313864.

Broj bitova u kojima se razlikuju odgovarajući šifrati nakon svake pojedine od 16 rundi DES-a prikazan je u sljedećoj tablici:

----------------------------------------------------------------------

runda 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

----------------------------------------------------------------------

broj bitova koji 1 6 21 35 39 34 32 31 29 42 44 32 30 30 26 29 34

se razlikuju

----------------------------------------------------------------------

Primer 2: Otvoreni tekst

68852E7A1376EBA4

šifriran je pomoću ključeva

E5F7DF313B0862DC i 64F7DF313B0862DC

koji se razlikuju samo u jednom bitu (i jednom paritetnom bitu: prvih 7 bitova su im 1110010 i 0110010). Broj bitova razlike u šifratima, po rundama, prikazan je u sledećoj tablici:

----------------------------------------------------------------------

runda 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

----------------------------------------------------------------------

broj bitova koji 0 2 14 28 32 30 32 35 34 40 38 31 33 28 26 34 35

se razlikuju

----------------------------------------------------------------------

Postavlja se pitanje zašto u DES-u imamo upravo 16 rundi. Primeri 1 i 2 sugerišu da već kod 3. runde efekt lavine dolazi do izražaja. Može se pokazati da nakon 5. runde svaki bit šifrata zavisi o svakom bitu otvorenog teksta i svakom bitu ključa, a nakon 8. runde šifrat je praktično slučajna funkcija bitova otvorenog teksta i ključa. Razlog da ipak imamo 16 rundi je u zahtevu da poznati kriptoanalitički napadi (kao što je npr. diferencijalna kriptoanaliza) ne budu efikasniji od napada "grubom silom".

▲▼▲

Originalna IBM-ova ponuda NBS-u je imala 112-bitni ključ. Prva IBM-ova realizacija Feistelove šifre - algoritam LUCIFER je imao 128-bitni ključ. Međutim, u verziji DES-a koja je prihvaćena kao standard dužina ključa je smanjena na 56 bitova (da bi ključ stao na tadašnje čipove, ali verovatno i pod uticajem NSA). Mnogi kriptografi su bili protiv tako kratkog ključa jer su smatrali da ne pruža dovoljnu sigurnost protiv napada "grubom silom". Uz 56-bitni ključ imamo 256 ≈ 7.2 · 1016 mogućih ključeva, pa se na prvi pogled napad "grubom silom" čini sasvim nepraktičnim. Međutim, već 1977. godine Diffie i


V01.2009

Page 26

Hellman su ustvrdili da tadašnja tehnologija omogućava konstrukciju računara koji bi otkrivao ključ za jedan dan, a troškove su procenili na 20 miliona dolara. Na osnovu toga su zaključili da je tako nešto dostupno samo organizacijama kao što je NSA, ali da će oko 1990. godine DES postati sasvim nesiguran. Godine 1993. Weiner je procenio da se za 100.000 dolara može konstruisati računar koji bi otkrio ključ za 35 sati, a za 10 miliona dolara onaj koji bi otkrio ključ za 20 minuta. Ipak sve su to bile pretpostavke i konačno razbijanje DES-a se dogodilo tek 1998. godine. Tada je Electronic Frontier Foundation (EFF) za 250.000 dolara zaista napravila "DES Cracker", koji je razbijao poruke šifrirane DES-om za 56 sati. Najpoznatiji napadi na ovaj algoritam su:

1. Brute force attack – ovim napadom se isprobavaju svi mogući ključevi i uz pomoć ove tehnike napada DES algoritam je razbijen 1998. uz pomoć Deep Crack računara.

2. Diferencijalna analiza - оtkrivena kasne 1980. od strane Elija Bihama i Adija Šamira, ali je bila poznata i ranije od strane IBM-a i NSA-a, ali je čuvana u tajnosti.

3. Linearna kriptoanaliza – uveo je japanski kriptolog Mitsuru Matsui 1993.

4. Unapređeni Dejvisov napad.

Za fiksni ključ K pomoću DES-a definisana je permutacija skupa {0,1}64. Dakle, skup od 256 permutacija dobijenih pomoću DES-a je podskup grupe svih permutacija skupa {0,1}64, čiji je red 264!. Postavlja se pitanje da li je DES (tj. skup svih njegovih permutacija) podgrupa ove grupe. Odgovor na to pitanje je negativan. Naime, skup svih DES-permutacija nije zatvoren. Preciznije, poznato je da je red podgrupe generisane svim DES-permutacijama veći o 22499. Ova činjenica je jako važna jer pokazuje da se višestrukom upotrebom DES-a može postići veća sigurnost. Posebno je popularan tzv. Triple-DES koji koristi tri koraka običnog DES-a s različitim ključevima. Kad bi DES činio grupu, Triple-DES ne bi bio ništa sigurniji od običnog DES-a.

Neki DES-ključevi su znatno nesigurniji od ostalih, pa ih svakako treba izbegavati. Prvi među njima su tzv. DES slabi ključevi. Kod njih su svi međuključevi K1, ... , K16 jednaki. To znači da su postupak šifriranja i dešifriranja doslovno jednaki. Dakle, vredi eK(eK(x)) = x. Drugim rečima, DES sa slabim ključem je involucija. Poznato je da šifriranje sa slabim ključem ostavlja 232 otvorenih tekstova fiksnim. Postoje tačno 4 DES slaba ključa. To su oni kod kojih se u rastavu PC1(K) = C0D0, leve i desne polovine C0 i D0 sastoje ili od samih nula ili od samih jedinica. Par ključeva (K,K') je par DES polu-slabih ključeva ako je kompozicija DES-ova s ključevima K i K' identiteta. Drugim rečima, šifriranje s jednim je isto kao dešifriranje s drugim. Kod DES-a s polu-slabim ključem, među 16 međuključeva K1, ... , K16 postoje samo dva različita; svaki od njih se koristi u po 8 rundi. Postoji točno 6 parova DES polu-slabih ključeva. Konačno, neki ključevi generišu samo 4 različita međuključa. Takvi se ključevi zovu DES potencijalno slabi ključevi i ima ih tačno 48. Sve u svemu, između 256 mogućih ključeva imamo samo 64 ključa koja treba izbegavati, pa je to lako i učiniti.

Načini delovanja Iako je sam opis DES-a dosta dug, on se može vrlo efikasno implementirati, i hardverski i softverski. Spomenimo da

je do 1991. godine u NBS-u registrovano 45 hardverskih implementacija DES-a. Godine 1992. proizveden je čip s 50000 tranzistora koji može šifrirati 109 bita (tj. 16 miliona blokova) po sekundi (čip je koštao 300 dolara).

Jedna važna primena DES-a je u bankarskim transakcijama. Tako se, između ostalog, DES koristio za šifriranje PIN-ova (personal identification numbers), te transakcija preko bankomata. DES je takođe do nedavno bio u širokoj upotrebi u civilnim satelitskim komunikacijama.

Do sada opisali kako radi DES na jednom bloku od 64 bita. U realnim situacijama, u kojima su poruke znatno duže, poznata su 4 načina delovanja (modes of operation) DES-a. Ti modovi pokrivaju sve moguće primene DES-a, a takođe su primenjivi na bilo koju simetričnu blokovnu šifru.

Najjednostavniji mod je ECB (Electronic Codebook) u kojem se svaki blok otvorenog teksta šifrira s istim ključem. Dakle, poruka se razbije na blokove od po 64 bita (zadnji blok se dopuni ako je nužno), pa se šifrira jedan po jedan blok koristeći uvek jedan te isti ključ.


V01.2009

Page 27

Slika 3.4 Electronic Codebook – ECB mod

ECB mod je idealan za kratke poruke, pa se često koristi za razmenu ključeva za šifriranje. Kod dugih poruka sigurnost ECB moda se smanjuje, budući da identični blokovi u otvorenom tekstu daju identične šifrate.

Da bi povećali sigurnost, želimo postići da identičnim blokovima u otvorenom tekstu odgovaraju različiti šifrati. Relativno jednostavan način da se to postigne je korišćenje CBC (Cipher Block Chaining) moda. Na trenutni blok otvorenog teksta se primeni operacija XOR sa šifratom prethodnog bloka, a tek potom se šifrira pomoću ključa K. Dakle, yi = eK(yi -1

xi) za i ≥ 1. Na startu uzimamo da je y0 = IV, gdje je IV tzv. inicijalizirajući vektor, koji mora biti poznat i primaocu i

pošiljaocu. To se može postići npr. tako da ga se pošalje ECB modom. Za dešifriranje koristimo relaciju xi = yi -1 dK(yi).

Slika 3.5 Cipher Block Chaining - CBC mod

U prethodna dva moda DES funkcionira kao blokovna šifra. No, od DES-a se može napraviti i protočna (stream) šifra. Prvi način je pomoću CFB (Cipher Feedback) moda. Kod protočnih šifri nema potrebe za proširivanjem poruke da bi se dobio celi broj blokova. To znači da će šifrat biti iste dužine kao otvoreni tekst. Obrađuje se odjednom j bitova (1 ≤ j ≤ 64). Najčešće je j = 1 ili j = 8. Ako je j = 8, to znači da se šifrira slovo po slovo (jednom slovu odgovara 8 bitova po ASCII standardu).

U šifriranje krećemo šifriranjem 64 bitnog inicijalizirajućeg vektora IV. Na j krajnje levih bitova izlaznog podatka primenimo XOR sa x1 i tako dobijemo y1. Ulazni podatak za sledeći korak šifriranja se dobije tako da se prethodni ulazni podatak pomakne za j mjesta ulevo, a na desni kraj se stavi y1. Postupak se nastavlja sve dok se sve jedinice otvorenog teksta ne šifriraju.


V01.2009

Page 28

Slika 3.6 Cipher Feedback - CFB mod

Kod dešifriranja se koristi ista šema, osim što se na odgovarajući šifrat primeni XOR s izlaznim podatkom funkcije šifriranja eK da bi se dobio otvoreni tekst. Uočimo da se ponovo koristi funkcija eK, a ne dK. Naime, ovde je funkcija šifriranja zapravo XOR, a on je sam sebi inverz. Zapravo, ovaj mod možemo shvatiti kao svojevrsnu realizaciju "jednokratne beležnice", u kojoj nam eK ne služi za šifriranje, već za generisanje "pseudoslučajnog" ključa za jednokratnu beležnicu. Ovo pokazuje da inicijalni vektor IV mora biti "svež", tj. ne bi se dvaput smeo koristiti isti inicijalni vektor.

OFB (Output Feedback) mod je vrlo sličan kao CFB. Jedina razlika je da se ulazni podatak za funkciju eK u idućem koraku šalje odmah nakon primene eK u prethodnom koraku (pre primene XOR-a). Jedna od prednosti OFB moda je da se greške u transmisiji ne propagiraju. Npr. greška u y1 utiče samo na x1. Ovaj mod se često koristi u šifriranju poruka sa satelita. Ali, ovo svojstvo može biti i nedostatak. Stoga se modovi CBC i CFB koriste za ustanovljavanje verodostojnosti poruke.

Slika 3.7 OFB mod

Pored ova četiri klasična načina delovanja, u poslednje vreme sve popularniji je CTR (Counter) mod. U njemu se koristi niz brojača (countera) c1, c2, ... . Niz blokova šifrata dobija se po sledećem pravilu:

yi = xi eK(ci).

Brojači moraju biti u parovima različiti. Obično se to postiže tak da se brojaču c1 pridruži neka inicijalna vrednost, a potom se ostali brojači povećavaju za 1: ci = c1 + (i - 1) (sabiranje je modul 2b, gdje je b dužina bloka; kod DES-a je b = 64).


V01.2009

Page 29

Slika 3.8 Counter - CTR mod

Za razliku od prethodna tri "ulančana" (chaining) moda, u CTR modu se šifriranje (i dešifriranje) može lako paralelizirati. Kod ulančanih modula je to bio problem jer je algoritam morao završiti obradu jednog bloka, da bi prešao na naredni. To pokazuje još jednu prednost CTR modusa, a to je mogućnost dešifriranja samo jednog određenog bloka, što može biti interesanstno za neke aplikacije. Slično kao kod CFB i OFB moda i ovde se u dešifiranju ponovo koristi funkcija eK (a ne dK). Ovo nije neka posebna prednost kod DES-a, ali može biti relevantno kod blokovnih programa za šifriranje kod kojih algoritam dešifriranja nije doslovno isti kao algoritam šifriranja (npr. AES).

PRIMER: Primena DES algoritma Konkretna primena DES algoritma pomoću CRYP TOOL-a sa kratkim i jasnim opisom :

Šta nudi CrypTool? CrypTool (www.crypTool.com) je freeware program u kojem možete upoznati, koristiti i analizirati različite

kriptografske tehnologije.

Deo CrypToola je opširna Online pomoć, koja je shvatljiva i bez prevelikog znanja iz područja kriptografije.

Na raspolaganju su vam:

• klasični (npr. Caesar i Doubbledice algoritmi) i

• moderni (npr. RSA- i AES-algoritmi, kao i algoritmi temeljeni na elptičnim krivuljama)

algoritmi.

Pregled svih algoritama za kriptovanje se nalazi u meniju "Crypt".


V01.2009

Page 30

Slika 3.9

Na slici Slika 3.9 je prikazana lista svih simetričnih algoritama koji spadaju u grupu modern.

Mi ćemo ovom prilikom samo obratiti pažnju na DES algoritam.

Slika 3.10

Poruka koju cemo da šifrujemo je tekst koji sadrži 167 reči, 886 karaktera (bez praznog prostora), 1051 karakter (računajući i one koji se koriste za razdvajanje), 2 paragrafa i 13 linija.

Koristićemo DES algoritam i najjednostavniji mod - ECB (Electronic Codebook) mod.

Kluč koji po kome će se vršiti proces enkripcije je: A1 B2 C3 D4 E5 F6 00 00


V01.2009

Page 31

Slika 3.11

Poruka koju smo dobili nakon pritiska na dugme encrypt izgleda ovako:

Slika 3.12

Sačuvamo kriptovanu poruku kao binary file (*.hex) i fajl možemo proslediti javnim kanalom. Primalac mora znati ključ, algoritam i metod kojim je kriptovana poruka, onda i te informacije šaljemo nekim od kanala.

Primalac otvara binary fajl, izabira algoritam i metod kojim je kriptovana poruka i upisuje ključ.


V01.2009

Page 32

Slika 3.13

Poruka se vraća u prvobitno stanje, odnosno tekst ponovo postaje razumljiv za krajnjeg korisnika.

Zaključak, DES algoritaam, primena Danas se DES algoritam sve manje koristi jer se ne može smatrati sigurnim algoritmom, i zbog relativno male dužine

ključa kao i zbog niza drugih nedostataka koji su omogućili kriptoanalitičarima širom sveta da objave niz algoritama za razbijanje DES-a.

Umesto njega sve viže se koristi AES (енгл. Advanced Encription Standard) algotitam i Triple DES – ovaj algoritam je ustvari unapređeni DES.

3.4.3 TWOFISH Twofish je simetrični kriptografski algoritam, proizvod kompanije Counterpane Systems nastao kao odgovor na izbor

američkog Nacionalnog Instituta za Standarde i Tehnologiju (NIST) objavljenog 1997. godine. Autori Twofish algoritma su Bruce Schneier, John Kelsey, Chris Hall, Niels Ferguson, David Wagner i Doug Whiting. Bruce Schneier je dizajnirao i Blowfish algoritam koji nije razbijen već 8 godina i koji je implementiran u preko 130 komercijalnih aplikacija. Twofish je dizajniran da bude veoma siguran i fleksibilan, može se upotrebiti u mrežnim aplikacijama gde se ključevi često menjaju i u aplikacijama gde ima malo memorije. Pogodan je za velike mikroprocesore, mikroprocesore 8 bit-nih smart kartica. Twofish je brz i na 8-bitnim i na 32 bit-nim procesorima. Counterpane Labs je proveo preko hiljadu sati analizirajući ga i algoritam je vrlo siguran kada se koristi 16 rundi, što nije slučaj kada se koristi samo 5 rundi. On je ujedno najbrži i najkompaktniji od svih AES kandidata.

Osnovne karakteristike

• veličina bloka koji se enkriptuje : 128 bita

• dužine ključa : 128, 192, 256 bita

• broj rundi: 16

Opis algoritma Algoritam spada u grupu koja koristi Feistel mreže (Feistel Networks), uz dodatno izbeljivanje na početku i na kraju.

Nakon svake Feistel runde izlaz se još dodatno rotira za 1 bit.Ulazni niz od 128 bita se prvo podeli na četiri 32 bitne reči. Svaka od reči se XOR-a sa jednim od èetiri kljuèa. Nakon toga sledi 16 Feistel rundi. Prve dve reči na levo služe kao ulaz u g funkciju (uz napomenu da je jedna od njih pre toga rotirana za 8 bita). g funkcija se sastoji od 4 S-tablice širine 8 bita koje su zavisne od ključa dotične runde. Nakon toga sledi linearno mešanje bazirano na MDS matrici. Izlazi g funkcija se kombinuju pomoću PHT (Pseudo Hadamard Transformation) i zbroje sa dva kljuèa. Zatim se to XOR-a sa dve krajnje desne reči (uz


V01.2009

Page 33

napomenu da se jedna od njih rotira za 1 bit pre toga, a druga posle). Leva i desna polovina zamene mesta i počinje sledeća runda. Nakon poslednje runde poništi se poslednja rotacija i ponovo se vrši izbeljivanje XOR-om sa četiri ključa.

Na sledećoj slici je prikazan Twofish algoritam.

Slika 3.14 Twofish algoritam

Poređenje Twofish-a sa ostalim algoritmima Twofish se pokazao kao vrlo siguran algoritam iako ga zbog kompleksnosti nije bilo moguće dobro ispitati u

vremenu koje je bilo predviđeno za odabir AES-a. Performanse su jako varirale zavisno o platformi i u hardverskim i u softverskim implementacijama ali ukupno, u odnosu na druge kandidate, nalazio se negde u sredini.

Pozitivne karakteristike ovog algoritma su sigurnost i vrlo velika fleksibilnost u pogledu zahteva za memorijom. Funkcije enkripcije i dekripcije su vrlo slične i zato hardverska implementacija enkripcije i dekripcije traži samo 10% više prostora u odnosu na implementaciju koja se sastoji samo od enkripcije.

Negativne karakteristike su to što vreme postavljanja ključeva značajno raste sa povećanjem ključa sa 128 bita na 192 ili 256 bita. Takođe je negativno i to što mu brzina varira zavisno o tipu platforme, ima ograničene mogućnosti paralelizacije procesa i naravno činjenica da je ukupno bio sporiji od pobednika Rijndael-a.


V01.2009

Page 34

3.5. Asimetricni kriptografski aalgoritmi 3.5.1 Kriptografija javnog ključa Kriptografske metode javnog ključa razvile su se kao rešenje problema razmene ključeva među strankama u

komunikaciji zaštićenoj kriptografijom tajnog ključa. Enkripcija tajnim ključem pati od velikog problema: kako će tajni ključ koji obe stranke trebaju poznavati da bi uspostavile komunikaciju stići od Helene Igoru ? Naime, ukoliko npr. Helena generira tajni ključ ona ga mora poslati Igoru, no to je osetljiva informacija koju bi trebalo enkriptirati. Nažalost, tajni ključ je Igoru potreban za dekripciju.

Šta je kriptografija javnog ključa ? Kriptografija javnog kluča, otkrivena 70-tih godina, rešava već spomenuti problem enkripcije poruka između dvie

stranke bez prethodnog dogovora o ključu.

U kriptografiji javnog ključa, Helena i Igor ne samo da imaju različite ključeve, već svako od njih dvoje ima dva ključa. Jedan Helenin ključ je privatni ključ i on ne sme biti poznat nikome osim Heleni. Drugi Helenin ključ je javni ključ i on može odnosno treba biti poznat svakome ko želi komunicirati sa Helenom.

Kad Helena želi poslati sigurnu poruku Igoru, ona enkriptira poruku koristeći Igorov javni ključ (koji ona poznaje). Igor koristi svoj privatni ključ (koji samo on poznaje) kako bi dekriptirao poruku. Kada Igor želi slati sigurnu poruku Heleni, on enkriptira poruku koristeći Helenin javni ključ(koji svi znaju) i rezultat enkripcije šalje Heleni. Helena koristi svoj tajni ključ da dekriptira Igorovu poruku. Ana može prisluškivati oba javna ključa i enkriptirane poruke, no ne može dekriptirati poruke pošto tajni ključevi od Helene niti od Igora nisu niti razmenjeni.

Javni i privatni ključ generiraju se u paru i trebaju biti većih dubljina nego tajni ključ ekvivalentne kriptografske snage koji se koristi u kriptografiji tajnog ključa. Tipične dubljine ključa za RSA algoritam javnog ključa je 1024 bita.Važno je napomenuti da je praktički neizvedljivo generisati privatni ključ na temelju javnog ključa (ovo se temelji se najčešće na problemu faktorizacije velikih brojeva).

Kriptografske metode javnog ključa su spore, u poređenju sa metodama tajnog ključa 100 do 1000 puta sporije. Tako da se u praksi najčešće koristi hibridbna tehnika. Naime, enkripcija metodama javnog ključa koristi se za distribuciju tajnog ključa ili sedničkog ključa (session key) drugoj stranci, a tada se tim sedničkim ključem obe stranke koriste za razmenu poruka primenjujući enkripciju tajnog ključa.

3.5.2 Asimetrični algoritam Kriptografija je pretežno matematička oblast, i njenu srž čine različiti kriptografski algoritmi,koji se primenjuju radi

obezbeđivanja tajnosti,integriteta, autentikacije i neporicanja. Jednu važnu klasu ovih algoritama čine takozvani asimetrični algoritmi, ili algoritmi koji koriste sistem javnog ključa (engl. public key algorithms, ili PK algorithms), pa se obično kaže da određeni sistem zaštite podataka koristi“kriptografiju sistemom javnog ključa” ako koristi takve algoritme. Asimetrični algoritmi su razvijeni relativno skoro: prvi takav algoritam (tzv. Diffie-Hellman algoritam) je nastao 1976.godine, a dve godine kasnije (1978.) je objavljen rad u kome je zasnovan najpoznatiji od tih algoritama – RSA algoritam.

Asimetrična kriptografija, poznata i pod nazivom kriptografija sa javnim ključem, to je oblik kriptografije u kojoj se ključ za kriptovanje poruke razlikuje od ključa za dekriptovanje. Drugim rečima, postoji javni i privatni ključ. Privatni ključ se drži u tajnosti, a javni može biti pružen mogućim pošiljaocima ili potpuno pušten u javnost. Kada pošiljalac šalje poruku, on je kriptuje javnim ključem, a primalac je dekriptuje privatnim ključem, koji samo on ima. Ova dva ključa su matematički povezani, ali privatni ne može biti otkriven preko javnog.

Pored uobičajenog kriptovanja poslatih poruka, asimetrična kriptografija se koristi i za digitalne potpise: određena poruka može biti potpisana privatnim ključem, a svi koji je prime mogu, pomoću javnog ključa, utvrditi da li je poruka poslata od prave osobe i da li je u netaknutom stanju tj. nepromenjena.

Budući da je asimetrično kriptovanje i dekriptovanje znatno zahtevnije od simetričnog, ova dva se često kombinuju; cela poruka se simetrično kriptuje pomoću ključa koji je izabran metodom slučajnog izbora, a zatim se taj ključ kriptuje primaočevim javnim ključem i šalje skupa sa porukom. Budući da je taj ključ obično znatno manji od cele poruke, njegovo asimetrično kriptovanje i dekriptovanje se odvijaju relativno brzo a simetrično dekriptovanje poruke je brzo samo po sebi. Na taj način je obezbeđena i sigurnost i brzina.

Zajednička osobina asimetričnih algoritama jeste korišćenje para ključeva, za razliku od tzv. simetričnih algoritama, koji koriste jedinstven ključ. Ključ predstavlja informaciju koja je potrebna algoritmu da bi obavio neku akciju, na primer kriptovao ili dekriptovao.


V01.2009

Page 35

Simetričan algoritam bi, na primer, za kriptovanje zahtevao zadavanje nekog ključa (npr. lozinke), pri čemu bi za dekriptovanje bila potrebna ista ta lozinka. Drugim rečima, da bi neko mogao da koristi simetričan algoritam za prenos podataka, a da zadovolji, na primer, zahtev tajnosti, on bi morao da nađe način da prethodno primaocu podataka prosledi ključ takođe uz zahtev tajnosti. Često je to nešto lakše nego preneti celokupan podatak (jer su ključevi obično mnogo kraći nego sami podaci, i lakše ih je preneti), ali svejedno problem prenosa podataka uz zahtev tajnosti ovim nije rešen.

Slika 3.15

Na slici Slika 3.15, koristi se neki veliki broj, izabran metodom slučajnog izbora, da bi se napravili odgovarajući privatni i javni ključ

Zbog svega ovoga, otkriće asimetričnih algoritama je predstavljalo pravu revoluciju u kriptografiji. Asimetrični algoritmi koriste par ključeva, pri čemu se jedan koristi za odgovarajuću operaciju (npr. kriptovanje), a drugi za suprotnu (npr. dekriptovanje). Pri tom je bitno da se jedan od ova dva ključa (nazvaćemo ga privatni ključ) ne može izvesti iz drugog

(nazvaćemo ga javni ključ) u “razumnom” vremenu (tj. vremenu koje na raspolaganju može imati potencijalni napadač). Iz privatnog ključa može i ne mora da bude izvodljiv javni, ali iz javnog ne sme da bude izvodljiv privatni.

Slika 3.16


V01.2009

Page 36

Na slici Slika 3.16,.bilo ko može kriptovati poruku koristeći javni ključ, ali samo imalac privatnog ključa može da je dekriptuje. Sigurnost sadržaja poruke zavisi od toga koliko se dobro čuva privatni ključ

3.5.3 Algoritmi javnog ključa Pod pojmom algoritma podrazumevamo precizno opisan postupak za rešavanje nekog problema. Obično je to spisak

uputstava ili skup pravila kojima je, korak po korak, opisan postupak za rešavanje zadatog problema. Svaki korak algoritma odnosno svako upustvo iz spiska mora da bude definisana operacija. Algoritmi moraju da budu nedvosmisleni i da se završavaju u konacnom broju koraka

RSA algoritam je svakako najpoznatiji i najviše primenjivan algoritam javnog ključa današnjice. Mnoge velike kompanije kao što su Microsoft, Apple, Sun i Novell su ga ugradile u svoje programe ili operativne sisteme. Takođe je našao mnoge primene i u sklopovlju tako da se koristi u širokom spektru proizvoda od sigurnih telefona, Ethernet mrežnih kartica sve do posebno dizajniranih kartica. Primenjuje se u gotovo svim važnijim načinima ostvarivanja sigurne komunikacije putem Interneta kao što su PGP, SSL, S-HTTP, SET, S/MIME, S/WAN i PCT.

Nažalost, RSA je patentiran od strane komapnije RSA Data Security, Inc. of Redwood City, California. Patent je pravovaljan do 2000. godine. Osim toga, izvoz i korišćenje RSA algoritma spada pod posebne zakone SAD-a. To znači da je izvoz u druge države (sa izuzetkom Kanade) programa koji koriste RSA za generiranje ključeva većih od 512 bajtova zabranjen bez posebne dozvole. Ipak, postoji i besplatna ne-Američka verzija RSA algoritma koja se opet ne sme koristiti u SAD-u, dok se u ostalom delu sveta sme koristiti bez ikakvih ograničenja.

3.5.4 RSA Algoritam RSA je algoritam za asimetričnu kriptografiju, prvenstveno namenjen šifrovanju podataka ali se danas koristi i u

sistemima elektronskog potpisa. RSA danas predstavlja industrijski standard u oblasti asimetične kriptografije i zaštiti podataka, tako da je široko primenjen u mnogim sigurnosnim protokolima i sistemi elektronskog poslovanja.

Istorijat RSA algoritma RSA je algoritam za asimetričnu kriptografiju nastao 1977. na MIT univerzitetu. Tvorci ovog algoritma su Ronald

Rivest, Len Adleman i Adie Šamir, gde RSA predstavlja akronim njihovih prezimena. Ova tehnika proizvodi javni ključ koji je povezan sa specifičnim privatnim ključem, koji je nemoguće dobiti samim znanjem javnog ključa. Poruka se šifruje javnim ključem i može da je dešifruje samo vlasnik privatnog ključa, dok ostali dobijaju besmisleni tekst.

Kliford Koks, britanski matematičar koji je radeći za jednu vladinu agenciju za komunikacije, još je 1973. godine objavio u internim dokumentima potpuno ekvivalentni sistem za asimetričnu kriptografiju, ali zbog poverljivosti tih dokumenata, to je tek objavljeno 1997.

Algoritam je patentiran od strane MIT-a 1983. u SAD,pod šifrom U.S. Patent 4,405,829. Patentna prava su istekla 21. septembra 2000.

Opis RSA algoritma U RSA algoritmu ključnu ulogu imaju veliki prosti brojevi. Sigurnost RSA zasniva se na složenosti faktorizacije

velikih brojeva. Smatra se da je određivanje originalne poruke na osnovu šifrata i ključa za šifrovanje ekvivalentno faktorizaciji proizvoda dva velika prosta broja.

Matematička osnova algoritma je u nemogućnosti faktorisanja velikih, celih brojeva, tj. činjenica da je lako naći proizvod dva prosta broja (brojevi deljivi samo sobom i jedinicom), ali ako je dat broj koji je proizvod dva prosta broja teško je naći koji brojevi pomnoženi daju taj proizvod (naći faktore datog broja).

Ilustrativan je brojni primer: 48611*53993=2624653723. Ovo se lako može dobiti olovkom i papirom. Teško je istim priborom naći faktore broja 2624653723, tj. brojeve 48611 i 53993. Računarom bi se problem lako rešio, ali samo dak su u pitanju mali brojevi.

Za formiranje digitalnog potpisa je najbitnije da je teško naći proste faktore datog broja. U protivnom postoje programi koji mogu da nađu tajni ključ i onda je stvar propala.

Rešenje je naći što veće proste brojeve, od više stotina decimalnih cifara (milijarda ima samo 9 cifara). Međutim postoji problem jer nijedan računar ne ume da pomnoži tako velike brojeve (prijavljuje grešku - prekoračenje).

Da bi smo i praktično primenili ovaj algoritam moramo da naučimo računar da sabira, oduzima množi, deli… tako velike brojeve, da izgradimo čitavu aritmetiku rada sa velikim brojevima, što znatno odudara od klasične predstave o aritmetičkim operacijama. Predlažemo da analizirate algoritme za sabiranje i množenje velikih brojeva i da pokušate da uradite odgovarajući program (predlažemo u C, C++) tj. da pokušate da dođete do praktičnog rešenja.


V01.2009

Page 37

Pogledajte postupak generisanja ključeva za RSA algoritam.

Postupak generisanja ključa za RSA algoritma Postupak generisanja ključa za RSA algoritam je sledeći:

1. Generisaćemo slučajno dva velika (različita) prosta broja p i q. (približno iste veličine).

2. Izračunaćemo sledeće proizvode:

3. n=p*q I t=(p-1)*(q-1).

4. Izabraćemo slučajan broj e, 1< e < t, tako da e i t osim broja 1, nemaju ni jedan drugi broj kojim su oba deljivi (uzajamno prosti).

5. Izračunaćemo broj d, 1 < d < t , tako da je broj e*d-1, bez ostatka deljiv brojem t.

6. Javni ključ je par (n,e), Privatni ključ je d.

Vlasnik privatnog ( neko kaže i tajnog ključa) d, slobodno može da objavi brojeve n i e, tako da svako ko želi da mu uputi tajnu poruku može to i učiniti, a njen sadržaj može čitati samo vlasnik privatnog ključa, dok ostali dobijaju besmislen tekst.

Primer: Ilustrativan je brojni primer (doduše sa malim brojevima ali je jasniji)

Osoba A formira javni i tajni ključ:

• izabrala je proste brojeve p = 2357 i q = 2551,

• izračunala je broj n = p*q = 6012707,

• izračunala je broj t = (p-1)*(q-1) = 6007800.

• bira slučajno broj e = 3674911 (deo javnog ključa),

• odgovarajućim (prošireni Euklidov) algoritmom računa d = 422191. tj. tajni ključ

Dakle javni ključ je par (n = 6012707, e = 3674911).

Da bi osoba B koja poseduje taj javni ključ, šifrovala poruku m = 5234673, osobi A mora da:

• računa c = me mod n = 52346733674911 mod 6012707 = 3650502. (gde mod označava ostatak pri deljenju, npr. 11 mod 3 = 2)

• Taj broj c = 3650502 (šifrat originalne poruke m) osoba B, šalje osobi A, koja pristupa dešifrovanju, odnosno koristeći broj d - tajni ključ računa:

cd mod n = 3650502422191 mod 6012707 = 5234673 (a taj broj je i originalna poruka m).

Ovo je dosta ilustrativan primer, jedino čitaoca može da čudi što šifrujemo brojeve a ne poruke koje su najčešće slova. Stvar je u tome što mi rečenične poruke i prevodimo u nizove nula i jedinica, dakle brojeve, na koje možemo primenjivati matematičke operacije. Kako to izgleda možemo da ilustrujemo sledećim primerom:

Neka poruka bude reč “Rat”, prevedeno na jezik 0, 1 tj. binaran broj oblika: n=( nl,...n1, n0 )

m = (0)10100100110000101110100. Svako slovo ima svoju decimalnu vrednost, odnosno odgovarajuću binarnu.

Dakle svakom slovu odgovara jedan broj manji ili jednak 127, i svaki takav broj se piše kao niz od 7 nula i jedinica, dok na osmom mestu stoji nula.

Npr. ako nekom slovu odgovara broj 82=1*26 +0*25 + 1*24 + 0*23 + 0*22 + 1*21 + 0*20, dakle karakter čiji ja kod 82 šifruje se u 01010010- to je kod slova R.

Slovu a odgovara broj 97=1*26+1*25+0*24+0*23+0*22+0*2+1, ili 1100001, s tim što na prvo mesto dodajemo nulu, zbog tehničkih rešenja na kojima počiva princip rada računara, tj. dopunićemo broj nula i jedinica do 8 (do jednog bajta). Dakle slovu a pridružujemo niz 01100001, a to je upravo srednja osmorka u poruci m.

U primeru koji sledi prikazaćemo postupak šifrovanja poruke.


V01.2009

Page 38

Očuvanje tajnosti, ili primer šifrovanja poruke 1. Neka poruka bude reč “Rat”, prevedeno na jezik 0, 1 tj. binaran broj oblika: n=( nl,...n1, n0 )

m = (0)10100100110000101110100.

Ponovimo: Svakom slovu odgovara jedan broj manji ili jednak 127, i svaki takav broj se piše kao niz od 7 nula i jedinica, dok na osmom mestu stoji nula. Dakle svaki karakter zamenjujemo sa nizom od 8 nula ili jedinica. Npr. ako nekom slovu odgovara broj 82=1*26 +0*25 + 1*24 + 0*23 + 0*22 + 1*21 + 0*20, dakle karakter čiji ja kod 82 šifruje se u 01000011- to je kod slova R.

2. Izaberimo dva 128-bitna prosta broja p i q:

p: 10000000000000000000000000010000000000000000000000000000000000 00000000000000010000000000000000000000000000000000000001010101 1111.

q: 10000000000000000000000000010000000000000000000000000000000000 00000000000000010000000000000000000000000000010000000000011100 1011.

Ovo su primeri za nas velikih, ali za računar,još uvek, malih (verovatno) prostih brojeva, u binarnom obliku i ne mogu se dobiti na klasičan način, poznatim algoritmima za detekciju i generisanje prostih brojeva.

3. n=p*q I t=(p-1)*(q-1)

n = p*q: 10000000000000000000000000100000000000000000000000000010000000 00000000000000100000000000000000000000000100010000000001110010 10100000001000000000111001010110000000000000000000000000000010 00000000111001010100000000000000000000101010111111001101000010 1010101.

t = ( p - 1 )*(q – 1 ): 10000000000000000000000000100000000000000000000000000010000000 00000000000000100000000000000đ00000000000100010000000001110010 10000000001000000000111001010010000000000000000000000000000010 00000000111001010000000000000000000000101010111101001100110100 0101100.

Za operacije množenja, sabiranja,… potrebno je izgraditi čitavu aritmetiku rada sa velikim brojevima, što znatno odudara od klasične predstave o aritmetičkim operacijama. Predlažemo da analizirate algoritme za sabiranje i množenje velikih brojeva i da pokušate da uradite odgovarajući program (predlažemo u C, C++)

4. Zatim biramo slučajan broj e, 1< e < t, tako da e i t osim broja 1, nemaju ni jedan drugi broj kojim su oba deljivi (uzajamno prosti). Biramo javni ključ e = 3 ili binarno 11.

Zatim računamo Privatni ključ broj d, 1 < d < t , tako da je broj e*d-1, bez ostatka deljiv brojem t.

Privatni ključ d: 10101010101010101010101011010101010101010101010101011000000000 00000000000000101010101010101010101010110000010101010111101110 00000000001010101011110111000010101010101010101010101010101101 01010110100001101010101010101010101011100011111100010001000101 110011.

Za one koji poznaju malo više algebru, napominjemo da je d ustvari inverzni elemenat za e u cikličnoj grupi.

Nakon računanja c = me mod n dobijamo šifrovanu poruku c:

10001000011111101010101101001011000011000101100100111000000101 000000.

Kada se ovo dešifruje dobila bi se poruka u binarnom obliku m = (0)10100100110000101110100 odnosno reč ‘Rat’

Šifrovanje obezbeđuje tajnost poruke ali ne štiti njen integritet, čak i ako ključ nije otkriven-“provaljen”. Nužno je razviti tehniku koja će snažno štititi integritet podataka tj. garantovati autentičnost sadržaja poruke. U tom cilju koristi se funkcija za sažimanje -hash funkcija.

Algoritmi za sabiranje i množenje velikih brojeva:

Algoritam za sabiranje: Ulaz: pozitivni celi brojevi x, y svaki sa n+1 cifrom u bazi b.

Izlaz: suma x + y = (wn+1...w1w0 )b.

1. c¬0 (prenos)

2. za i = 0, ..., n ponoviti sledeće korake:


V01.2009

Page 39

2.1. wi = (xi + yi + c) mod b

2.2. Ako je (xi + yi + c) < b onda je c¬0 inače je c¬1

3. wn+1¬ c

Izlaz (wn+1...w1w0 )b.

Uputstvo:

Osnova brojnog sistema će biti 2. xI , yI će biti 0 ili 1.

Algoritam za množenje: Ulaz: pozitivni brojevi x, y koji imaju n+1 i t+1 cifara.

Izlaz: xy= ( wn+t+1...w1w0 )b.

1. za i = 0, ..., n+t+1 dodeliti wi¬ 0

2. za i = 0, ..., t ponoviti sledeće korake:

2.1. c¬0

2.2. za j = 0, ... , n ponoviti sledeće korake:

Izračunati (uv)b= wi+j+ xj yi+ c

wi+j¬v, c¬u

2.3. wi+n+1= u

3. Izlaz ( wn+t+1...w1w0 )b.

3.5.5 RSA digitalni potpis Krajnje izlaganje po ovoj temi je posvećeno digitalnom potpisu. Pošto se u elektronskoj komunikaciji javila potreba

za prenošenjem poruka, morala se pronaći tehnika koja će biti digitalni pandan svojeručnog potpisa, digitalni potpis.

Digitalni potpis je matematički algoritam koji osigurava da je data informacija potekla od datog entiteta. Digitalni potpis poruke je transformat poruke koji zavisi od nekih tajni poznatih samo potpisivaču i, dopunski, od same poruke koja će biti potpisana.

Sam koncept i korisnost digitalnih potpisa bili su poznati i nekoliko godina pre prve praktične realizacije. Prvi metod je bio RSA šema potpisa koji je i danas najpraktičnija i najdomišljatija tehnika kojom raspolažemo.

RSA Šema digitalnog potpisa je sledeća:

Osoba koja potpisuje poruku m, nalazi njenu hash vrednost, neka je to m’, formatira tu poruku u skladu sa usvojenim standardima i računa:

s = (m’)d mod n.

Potpis je s, a na raspolaganje se stavlja i m (poruka).

Primalac poruke: Pomoću javnog ključa (n, e) računa m” = se mod n.

Ukoliko su te dve vrednosti, m’ i se mod n, iste, prihvata poruku, znajući da je očuvan integritet podataka i da je poruku zaista potpisao vlasnik tajnog ključa.

Primetimo da se za razliku od RSA šifrovanja prvo primenjuje privatni, a zatim javni ključ.

Uskoro ćemo vam ponuditi preuzimanje paketa za digitalni potpis, a za probu ćemo prvo ponuditi računanje hash vrednosti, i sa nestrpljenjem ćemo očekivati čitaoca koji će naći poruku koja će imati istu hash vrednost kao poruka: e-trgovina.

Na kraju ovoga teksta, pozivamo čitaoce da svojim angažovanjem promene, dopune,… ovu rubriku. Ona će moći da se dograđuje i menja u skladu sa Vašim interesovanjem i predlozima.


V01.2009

Page 40

Mogući pravci daljeg razvoja su:

1. Upoznavanje sa primenama digitalnog potpisa u poslovanju ( izdavanje sertifikata, onemogućavanje poricanja izvršene radnje, itd.)

2. Razmatranje slabosti RSA, mogućnost kriptoanalize.

3. Protokoli, načini distribucije ključeva itd.

4. Izgradnja softvera u Javi za digitalno potpisivanje poruke (kombinovano zbog brzine sa C++), ili nešto skromniji ali odlučujući zadatak rešavanja modularne eksponencijacije ( me mod n.).

3.5.6 Nedostaci RSA algoritma Prosti brojevi koji se koriste u ovom algoritmu uglavnom sadrže nekoliko stotina cifara i zbog toga se ovde javljaju

više problema praktične prirode. Da bise pomnožili toliko veliki brojevi, moraju se koristiti posebni algoritmi za množenje. Sem toga lako se da primetiti da je za takve operacije potrebno više vremena, pa su tako ovi algoritmi šifrovanja mnogo sporiji u odnosu na simetrične algoritme. DES algoritam šifrovanja je oko 100 do 1000 puta brži u odnosu na RSA algoritam. Sem ovoga algoritmi za faktorizaciju brojeva postaju svakim danom sve bolji, kao i neumoljiv razvoj kompjutera učinili su da danas 512 bitni RSA algoritam ne bude dovoljan za bezbedno šifrovanje poruka, za 1024 bitne algoritme pretpostavlja se da će biti bezbedni barem još 15-tak godina.

3.6. Hibridni algoritmi: Kombinovana simetrična i asimetrična kriptografija Kod kombinovane kriptografije iskorišćene su najbolje osobine simetrične i asimetrične kriptografije.Naime,

šifrovanje asimetričnim algoritmima je do hiljadu puta sporije nego sa simetričnim, tako da je šifrovanje obimnijih podataka primenom asimetričnih algoritama nepraktično. Sa druge strane, kod simetričnih algoritama veliki problem predstavlja distribucija i upravljanje ključevima. Zato se primenjuje kombinovana kriptografija kod koje se za šifrovanje podataka primenjuju simetrični algoritmi, dok se asimetrični algoritmi koriste za razmenu simetričnih ključeva.

3.6.1 Šifrovanje i dešifrovanje dokumenata Šifrovanje dokumenta od strane korisnika A za korisnika B se vrši na sledeći način (slika 3.). Korisnik A u svojoj

klijentskoj aplikaciji izabira dokument koji želi da šifruje i korisnika B kome želi da pošalje šifrovan dokument. Izborom korisnika B, klijentska aplikacija pretražuje javni imenik i pronalazi javni ključ korisnika B. Zatim, aplikacija generiše simetrični ključ (ključ sesije) i primenom njega i simetričnog algoritma šifruje dokument, i tako formira šifrovan dokument. Sa druge strane, simetrični ključ se šifruje javnim ključem korisnika B primenom asimetričnog algoritma. Datoteka za korisnika B se sastoji od šifrovanog dokumenta i šifrovanog simetričnog ključa.

Slika 3.17 Šifrovanje dokumenta

Dešifrovanje dokumenta na strani korisnika B se vrši na sledeći način (slika 4.). Klijentska aplikacija korisnika B prvo dešifruje šifrovan simetrični ključ primenom tajnog ključa korisnika B i asimetričnog algoritma. Zatim, aplikacija


V01.2009

Page 41

dešifruje šifrovan dokument primenom simetričnog ključa i simetričnog algoritma. Posle toga, korisnik B može da pogleda sadržaj dokumenta.

Slika 3.18 Dešifrovanje dokumenta

3.6.2 Hibridni sistem šifriranja – kriptosistem (Hybrid encryption sistem - Cryptosystem) U kriptografiji pogodni su za korišćenje kriptosistemi sa javnim ključem zato što nisu potrebni pošiljaoc i primalac

da dele zajedničku tajnu radi sigurnije komunikacije. Ali, ovi kriptosistemi se oslanjaju na komplikovane matematičke obračune što je generalno mnogo manje efikasnije od upoređivanja simetičnih ključeva kad nekih kriptosistema. U mnogim primenama visoka cena enkriptovanja (šifriranja) dugačkih poruka javnim ključem kod kriptosistema može biti obustavljena.

Hibridni kriptosistem jeste onaj kriptosistem koji kombinuje pogodnost javnog ključa (public-key) nekog kriptosistema sa efikasnošću (produktivnošću) simetričnog ključa (simmetric key) nekog drugog kriptosistema.

Ovaj hibridni kriptosistem može biti konstruisan korišćenjem bilo koja dva odvojena kriptosistema:

• šemom enkapsulacionog ključa, što je u stvari kriptosistem javnog ključa i

• šemom enkapsulacionog podatka, što je kriptosistem simetričnog ključa.

Hibridni kriptosistem je sam po sebi sistem sa javnim ključem, čiji su javni i privatni ključevi isti kao u šemi enkapsulacije ključa. Važno je napomenuti da se za veoma dugačke poruke većina posla oko šifriranja i dešifrovanja obavlja preko efikasnije šeme za simetrični ključ, dok se neefikasne šeme za javni ključ koriste jedino da šifriraju ili dešifruju ključ sa nekom kratkom vrednošću.

Dakle, glavni cilj ovog hibridnog metoda je da izjednači dotične nesuglasice simetrične i asimetrične enkripcije i da kombinovanje njihove prednosti. Glavni problem kod svih algoritama sa simetričnim šifriranjem jeste upravljanje ključem za veliki broj tajnih ključeva (po jedan tajni ključ sleduje komunikacijskim partijama). Ovaj problem rešava asimetrična kriptografija. S druge strane, simetrični algoritmi su mnogo brži od asimetričnih.

Sistemi sa asimetričnom ekripcijom su, pored svojih velikih obračuna potrebština, korišćeni jedino u vežbi samo za šifriranje takozvanih “sesijskih ključeva” (session keys). Uneseni podatak se šifrira simetričnim algoritmom preko sesijskog ključa. Ova kombinacija dva metoda se naziva hibridno šifriranje (hybrid encription) simetrično ili asimetrično. Ovo ukazuje da nije moguć nikakav nedostatak u obezbedjenju ukoliko se koristi dobar generator za broj sesijskog ključa.

U hibridnim enkripcijskim (šifarničkim) sistemima pošiljaoc A kreira u sigurnoj okolini proizvoljan ili nepredvidiv simetrični ključ “S” (takozvani sesijski ključ) i korišćenjem ove poruke šifrira poruku. Pošiljaoc onda šifrira sesijski ključ asimetričnim (javnim) ključem pošiljaoca B. I onda poruka koja je šifrirana sa “S” zajedno sa sesijskim ključem se emituju primaocu.

Primaoc B, koji ne zna sesijski ključ, treba da dešifruje šifrirani sesijski ključ pre nego što dešifruje poruku. “S” dešifruje svojim asimetričnim privatnim ključem. I sada zna sesijski ključ kojim može dešifrovati poruku koja mu je poslata.

U CrypTool programu postoje da hibridna sistema za šifriranje:

• Hibridno šifriranje sa RSA-AES-om, i

• Hibridno šifriranje sa ECC-AES-om.

Važno je reći da je hibridno šifriranje danas najrasprostranjeniji metod prenosa šifriranih podataka.


V01.2009

Page 42

Primer: Ako želimo da šifriramo poruku koja je adresirana osobi A (Anica) u hibridnom sistemu, osoba B (Boki) treba da

uradi sledeće:

1. da nabavi od Anice javni ključ;

2. napravi novi simetrični ključ za šemu enkapsulacije podataka;

3. šifrira poruku po šemi enkapsulacije podataka, koristeći tek stvoreni simetrični ključ;

4. šifrira simetrični ključ po šemi enkapsulacije ključa, koristeći Anicin javni ključ;

5. i na kraju da pošalje obe šifrirane predmete (šifrirani simetrični ključ I šifriranu poruku) Anici.

Da bi Anica dešifrovala ovaj hibridni šifrat mora da uradi sledeće:

• da upotrebi svoj privatni ključ kako bi dešifrovala simetrični ključ koji se nalazi u segmentu enkapsulacije ključa;

• i da onda upotrebi ovaj simetrični ključ za dešifrovanje poruke koja je sadržana u segmentu enkapsulacije ključa.

Hibridno šifriranje preko RSA-AES u programu : Sistem za hibridno šifriranje dodaje odgovarajućem dokumentu simetrični šifrat (u ovom slučaju AES) preko

sesijskog ključa. A onda se sesijski ključ šifrira asimetričnim šifratom (tj. RSA).

Kreirani šifrat se može dešifrovati preko opcije za dešifrovanje, tj. Preko jezička (dialog box-a) hybrid decryption with RSA-AES, do kojeg se dolazi preko Crypt/Decrypt \ Hybrid \ RSA-AES Encryption.

Ovde je moguće izvršiti hibridno dešifrovanje postepeno korak po korak i to lično može uraditi korisnik, pa tako može imati jasan pregled. Isto važi i za šifriranje.

Slika 3.19 Početni dijagram toka hibridne enkripcije

Ovako izgleda početni dijagram toka hibridne enkripcije (šifriranja).

Pre nego što se otvori ovaj jezičak hibridne enkripcije potrebno je kreirati asimetrični ključ, tako što se u jezičku Digital Signatures/PKI klikne na PKI, zatim na Key Generation/Import gde se mogu naći odgovarajući alati za kreiranje RSA parova ključa i oni se mogu uskladištiti u bazu podataka CrypTool programa (PSE file).

Na dijagramu toka trenutno su raspoloživa samo tri početna polja, a njivovim daljim razvijanjem i grananjem aktiviraće se i ostala polja i to korak po korak.


V01.2009

Page 43

Slika 3.20 Dijagram toka sa završenim hibridnim šifriranjem

Prikazan je dijagram toka sa završenim hibridnim šifriranjem.

Nakon više otvorenih polja u donjem prozoru će se ukazati podatak usled generisanja i njega je moguće videti klikom na polje Save. Ovaj podatak je bitan zato što se on kasnije može upotrebiti kao ulazna veličina u procesu dešifrovanja, što menja ceo proces šifriranja.

Ove ponuđene mogućnosti hibridnog šifriranja u programu su dizajnirane tako da se njima može eksperimentisati, kao i zabavljati. Svaki je proces smesten u polje odgovarajućeg oblika i boje.

Simbol za uvodne korake (odabir nekog file-a)

Simbol za procese podataka (session key)

Simbol za skladište podataka (asymmetric key)


V01.2009

Page 44

Simbol za neku standardnu proceduru koju treba izvršiti.

Crvena boja Otvaranje zadataka (preparation / input / processes)

Zelena boja Odrađeni zadaci (preparation / input / processes)

Plava boja Dostupni podaci (display and further processing possible)

Siva boja Neaktivni podaci (unavailable data / processes with missing input data)

Međuzavisnost polja i koraka pri grananju je prikazana strelicama između odgovarajućih simbola. Aktivna polja (crvena/zelena/plava) se mogu selektovati proizvoljno i to više puta. Neaktivna polja sive boje ne mogu se selektovati. Procesi se aktiviraju samo onda kada su svi početni uslovi ispunjeni. Ovaj dijagram toka je podeljen u četiri reda:

1. U prvom se redu nalaze početni koraci koje je potrebno izvršiti pre bilo koje enkripcije;

2. Red broj dva sadrži simbole za one elemente podataka koje je proizveo prvi red, a podaci se mogu prikazati samo klikom na simbol;

3. Treći red sadrži procedure pti šifriranju;

4. Zadnji red prikazuje šifrirani dokument i šifrirani sesijski ključ.

Ukoliko je lista RSA ključeva prazna, to znači da se moraju kreirati parovi ključeva za primanje korisničkog meniija Key Management / Key Generation.

3.6.3 RSA šifrovanje u hibridnom kriptosistemu RSA je algoritam za asimetričnu kriptografiju, prvenstveno namenjen šifriranju podataka, ali se danas koristi i u

sistemima elektronskog potpisa. RSA danas predstavlja industrijski standard u oblasti asimetrične kriptografije i u zaštiti podataka, tako da je široko primenjen u mnogim sigurnosnim protokolima i sistemima elektronskog poslovanja.

Slika 3.21 RSA šifrovanje


V01.2009

Page 45

Na slici Slika 3.21 RSA šifrovanje prikazano je RSA šifriranje.

3.6.4 Opis rada algoritma RSA jeste algoritam za asimetričnu kriptografiju nastao 1977. na MIT univerzitetu. Tvorci ovog algoritma

su Ronald Rivest, Len Adleman i Adie Šamir, gde RSA predstavlja skraćenicu njihovih prezimena. Kliford Koks, britanski matematičar koji je radeći za jednu vladinu agenciju za komunikacije, još je 1973. godine objavio u internim dokumentima potpuno ekvivalentni sistem za asimetričnu kriptografiju, ali zbog poverljivosti tih dokumenata, to je tek objavljeno 1997.

Algoritam je patentiran od strane MIT-a 1983. u SAD-u, pod šifrom U.S. Patent 4,405,829. Patentna prava su isteklja 21. septembra 2000.

U RSA algoritmu ključnu ulogu imaju veliki prosti brojevi. Sigurnost RSA zaniva se na složenosti faktorizacije velikih brojeva. Smatra se da je određivanje originalne poruke na osnovu šifrata i ključa za šifriranje ekvivalentno faktorizaciji proizvoda dva velika prosta broja.

Postupak generisanja ključa za RSA algoritam :

1. Generisaćemo slučajno dva velika (različita) prosta broja i pri čemu je

2. Izračunaćemo sledeće proizvode:

3. I Ojlerovu funkciju:

4. Odabere se celobrojna vrednost pri čemu je

5. Izračuna se pri čemu je

6. Javni ključ je par , Privatni ključ je par .

Šifriranje poruke Generisanje ključeva: Osoba A formira i javni i tajni ključ:

1. izabrala je proste brojeve ,

2. izračunala je broj ,

3. izračunala je broj .

4. bira slučajno broj (deo javnog ključa),

5. odgovarajućim (prošireni Euklidov) algoritmom računa , tj. Tajni ključ.

Dakle javni ključ je par (n = 6012707, e = 3674911).

Šifriranje poruke: Da bi osoba B koja poseduje taj javni ključ, šifrirala poruku

m = 5234673 osobi A mora da:

1. računa ,

2. Taj broj c = 3650502 (šifrat originalne poruke m) osoba B šalje osobi A, koja pristupa dešifrovanju, odnosno koristeći broj d – tajni ključ računa.

Dešifrovanje poruke: Koristeći broj d – tajni ključ osoba A računa:

a taj broj je i originalna poruka m.

Nedostaci algoritma Prosti brojevi koji se koriste u ovom algoritmu uglavnom sadrže nekoliko stotina cifara i zbog toga se ovde javlja

više problema praktične prirode. Da bi se pomnožili toliko veliki brojevi, moraju se koristiti posebni algoritmi za množenje. Sem toga lako se da primetiti da je za takve operacije potrebno više vremena, pa su tako ovi algoritmi šifriranja mnogo sporiji


V01.2009

Page 46

u odnosu na simetrične algoritme. DES algoritam šifriranja je oko 100 do 1000 puta brži u odnosu na RSA algoritam. Sem ovoga algoritmi za faktorizaciju brojeva postaju svakim danom sve bolji, kao i neumoljiv razvoj kompjutera učinili su da danas 512-o bitni RSA algoritam ne bude dovoljan za bezbedno šifriranje poruka, za 1024-o bitne algoritme predpostavlja se da će biti bezbedni barem još 15-ak godina.

3.6.5 AES šifriranje U kriptografiji, Advanced Encryption Standard (AES) Napredni Enkripcioni standard, takođe poznat kao Rijndael, je

blok šifra koji je usvojen kao standard za kriptovanje od strane Američke vlade. On je bio opsežno analiziran i sada se koristi u celom svetu, kao što je bio slučaj sa njegovim prethodnikom, Data Encryption Standard (DES). AES je najavio nacionalni institut za standarde i tehnologiju (NIST), kao i US FIPS PUB 197 (FIPS 197) 26. novembra 2001. godine nakon petogodišnjeg procesa standardizacije u kojem su se takmičila petnaest dizajna koji su prezentirani i vrednovani pre nego što je Rijndael odabran kao najviše pogodan (vidti Advanced Encryption Standard proces za više detalja). Postao je efikasan kao standardan 26. maja 2002. kao od 2006, AES je jedan od najpopularnijih algoritama koji se koristi u simetričnom ključu kriptografije. ABS je dostupan po izboru u mnogim različitim paketima enkripcije. AES je javno dostupan i otvoreni algorimat odobren od strane NSA za informacije visoke tajnosti (vidi sigurnosti AES, ispod).

Ovaj novi standard američke vlade za zaštitu osetljivih podataka smislili su Joan Daemen i Vincent Rijmen, poznati Belgijski kriptografi. Joan radi u kompaniji Proton World International, dok Vincent radi na belgijskom Katoličkom univerzitetu.

Mašine kojima bi za razbijanje šifre kodirane po DES-u trebala svega 1 sekunda, kakve su sada, u eri razvijene računarske tehnologije česti, na AES bi potrošili 149 triliona godina. Amerikancima ne smeta ni činjenica da je sistem izrađen u inostranstvu, jer su kompletni algoritmi i načela dizajna već dve godine bili dostupni Pentagonovoj National Security Agency na uvid i testiranje.

Slika 3.22 Dijagram AES algoritma

Zamena bita

Zamena redova

Mešanje kolona

Dodavanje kružnog ključa


V01.2009

Page 47

Slika 3.23 AES Proces Enkripcije

Opis postupka enkripcija Strogo govoreći, AES nije precizno Rijndael (iako u praksi oni se koriste nerazdvojivo), jer Rijndael podržava veći

raspon bloka i veličine ključa; AES ima fiksni blok veličine 128 bita i ključ veličine 128, 192, ili 256 bita , dok kod Rijndaela može biti navedena, uz ključ, i veličina bloka u bilo kojoj vrednosti pomnoženoj sa 32 bita, i najmanja je 128 bita, a najviša 256 bitova.

Budući da u računarstvu 1 bajt iznosi 8 bitova, stalnih blok veličine 128 bita je obično 128 ÷ 8 = 16 bajta. AES radi na 4 × 4 niza bajtova, određuje stanje (verzije Rijndaela sa širim blokom veličine imaju dodatne kolone u stanju). Većina AES kalkulacije su obavljene u posebnom konačnom polju.

Kriptovanje je određeno u uslovima ponavljanja obrade koraka koje se primjenjuju kako bi nadoknadili krugove ključem transformacije između ulaznih plain-text i konačnom izlazu kriptovanog teksta. A set obrnut runde su primjenjivane za transformaciju kriptovanja teksta natrag u izvorni plain-text, pomoću istog ključa za šifriranje.

High–level algoritam kriptovanja Proširenje ključa koristeći Rijndael ključni raspored Inicijalni krug enkripcije

1. Dodavanje kružnog ključa - Okrugli

2. Zamena bitova-a ne-linearna zamena koraka gde je svaki bajt zamijenjen sa drugim prema tabeli.

3. Pomeranje redova-a je korak gde je svaki red u stanju pomeren kružno za određeni broj koraka.

4. Mešanje kolona-a, operacija mešanja, koja deluje na kolone u stanju, kombinujući četiri bytes u svakoj koloni.

5. Dodavanje kružnog ključa - svaki bajt stanja je u kombinaciji sa okruglim ključem; svaki okrugao ključ je izveden iz ključa za kriptovanje informacija koristeći generisanje ključa.

Poslednji krug (nema Mešanja kolona)

1. Zamena bitova

2. Pomeranje redova

3. Dodavanje kružnog ključa


V01.2009

Page 48

Tabela 3.1 Postupak zamena bitova

Postupak zamena bitova, jedan od četiri nivoa u AEs-u

Glavno

Dizajneri Vincent Rijmen, Joan Daemen

Prvo izdanje 1998

Izveden iz Square

Nasldnici Anubis, Grand Cru

Sertifikat AES winner, CRYPTREC, NESSIE

Detalji kriptovanja

Veličina ključa

128, 192 or 256 bits

Veličina bloka

128 bits[2]

Struktura Substitucija-permutacija mreža

Krugovi 10, 12 ili 14 (zavisno od veličine ključa)

Najbolje javne kriptoanalize

Napad Povezanim ključem može da može da otkrije 9 kruga od 256-bitnog AES-a. Napad umtnutim tekstom može da otkrije 8 krugova 192 i 256-bitnog AES-a i 7 krugova 128 bitnog AES-a. (Ferguson et al, 2000)

Sigurnost Ako su oba, ključ i šema kriptovanja podataka tajne, sigurne su od raznih prilagodljivih napada, tada hibridne šeme

će biti nasleđene dobro. Međutim, moguće je konstruisati hibridne šeme koje su sigurne od raznih napada, čak i ako kriptovanje ključem ima ponešto oslabljenu definiciju sigurnosti (mada sigurnost kriptovanja podataka mora biti malo jača).

3.6.6 Hibridni algoritmi: zaključak Kada je pismo postalo sredstvo komunikacije, pojavila se potreba da se neka pisma sačuvaju od tuđih pogleda. Tada

je i kriptografija ugledala svetlost dana. Od samog početka, enkripcija podataka koristila se prvenstveno u vojne svrhe.

Pojavom prvih kompjutera otvorila su se nova vrata kriptografiji. Kompjuteri su vremenom postajali sve brži i brži, radeći i po nekoliko stotina, a kasnije i miliona operacija u sekundi. Novom brzinom rada je omogućeno probijanje šifri za sve manje vremena. Uporedo s tim, radilo se i na izmišljanju novih, sigurnijih i komplikovanjih algoritama za enkripciju.

Enkripcija je podeljena na dva dela:

• simetričnu i asimetričnu enkripciju.

Simetrična enkripcija predstavlja šifrovanje poruka, pri čemu i za šifrovanje i za dešifrovanje koristimo istu šifru (ključ). Kod asimetrične postoji poseban ključ samo za šifrovanje i drugi koji služi samo za dešifrovanje. To je, u stvari, i jedina velika razlika između ova dva načina enkripcije.

Kod simetrične enkripcije koristi se isti ključ i za šifrovanje i za dešifrovanje. Baš zbog toga je raznovrsnost, a samim tim i sigurnost algoritama ovakve enkripcije velika. Bitan faktor je i brzina - simetrična enkripcija je veoma brza. Pored svih prednosti koje ima na polju sigurnosti i brzine algoritma, postoji i jedan veliki nedostatak. Kako preneti tajni ključ? Problem je u tome, što ako se tajni ključ presretne, poruka se može pročitati. Zato se ovaj tip enkripcije najčešće koristi prilikom zaštite podataka koje ne delimo sa drugima (šifru znate samo vi i nju nije potrebno slati drugome).


V01.2009

Page 49

Za razliku od simetrične enkripcije, asimetrična koristi dva ključa - javni i tajni. Princip je sledeći: na osnovu tajnog ključa koji zadajemo, generiše se javni ključ. Javni ključ dajemo osobama koje nam šalju šifrovane podatke. Pomoću njega, ta osoba šifrira fajl koji želi da nam pošalje i takvog nam ga pošalje. Kada nam enkriptovani fajl stigne, mi ga dešifrujemo pomoću našeg tajnog ključa. Znači, tajni ključ imate samo vi, a javni ključ može imati bilo ko, pošto se on koristi SAMO za šifrovanje, a ne i dešifrovanje.

Najveći deo administrativnih poslova danas se obavlja na računarima i postalo je neophodno obezbediti sigurnost svih unesenih podataka. Sistemi za plate, obračune, naloge i drugo moraju da budu i ostanu zaštićeni, a sa poslednjim talasom sigurnosnih rupa u operativnim sistemima to postaje sve teži zadatak. Trend je izrodio pravi bum na tržištu za računarsku sigurnost. Svakodnevno se pojavljuju novi programi koji obećavaju najefikasniju zaštitu podataka koji su po rečima svojih autora „baš ono što vam nedostaje da biste bili sasvim sigurni”.

Dodavanje ekstra sloja sigurnosti kriptovanjem podataka je pravi put: čak i ako je operativni sistem kompromitovan, kriptografska barijera stoji nezavisno, te je potencijalni napadač onemogućen. Biranje pravog kriptografskog paketa ili dodataka ozbiljna je i zahtevna stvar, gotovo osetljivija od izbora aplikativnog softvera, jer kriptografski softver ima samo jednu namenu i ne sme da „pogreši” nijednom. Bitno je znati kako da se ne napravi pogrešan izbor.

3.7. Digitalni potpis, HASH 3.7.1 Uvod Današnji opšte prihvaćeni način overavanja dokumenata svojeručnim potpisom vuče korene od samih početaka

ljudske pismenosti. Potpisi se danas nalaze na najrazličitijm dokumentima, od različitih ugovora, naloga, čekova pa sve do privatnih pisama. Prema postojećim zakonima potpisom se smatra ne samo svojeručni potpis, već i bilo koji drugi znak na dokumentu načinjen s ciljem overavanja dokumenta. Ipak, na računarima se ne smatra svaki potpis digitalnim potpisom. Različite znakovne ili tekstualne oznake u datotekama ili elektronskoj pošti ili kopije vlastoručnog potpisa krajnje su neprimerene i nepouzdane, pre svega zbog trivijalnog krivotvorenja. Razvojem i širenjem računara a najpre računarskih mreža, postalo je jasno da je potreban potpuno novi način overavanja. Temelji za pouzdanu proveru porekla informacija, «digitalni potpis», stvoreni su 1976. godine otkrićem kriptografije javnog ključa (Diffie-Hellman), koja se još naziva i asimetričnom kriptografijom. Zanimljivo je napomenuti da je ovaj način kriptovanja podataka, prema nekim informacijama [J H Ellis: The Possibility of Secure Non-Secret Digital Encryption, CESG Report, January 1970] bio poznat britanskoj tajnoj službi nekoliko godina pre nego spomenutoj dvojici istraživača.

Danas, kada većina razvijenih zemalja u svoje zakone uvodi i zakon o digitalnom potpisu, ovo područje se nalazi na granici dva sveta, kriptografije i prava. Osim pravnih problema oko primene digitalnog potpisa, postoje i pravni problemi vezani uz implementaciju algoritama digitalnog potpisa, uglavnom zbog softverskih patenata kojima je velik broj algoritama zaštićen, ali i zbog restriktivnih regulativa pojedinih zemalja vezanih uz kriptografske proizvode uopšte. Tako je npr. izvoz «jakog» enkripcijskog softvera iz SAD-a bio zabranjen sve do pred kraj 1999. godine. Isto tako, u Francuskoj je upotreba alata za enkripciju bila zabranjena do početka 1999. Ipak, naglim širenjem elektronskog poslovanja postalo je nužno ovakve odredbe ukinuti, i omogućiti kako sigurnu zaštitu informacija šifriranjem tako i zaštitu od mogućih prevara, autentifikacijom. Upravo idealnim za ovo poslednje nameće se digitalni potpis.

3.7.2 Osnovni principi rada digitalnog potpisa Pretpostavimo da dvoje ljudi A i B, žele da razmenjuju potpisane poruke (podatke) tj. žele biti sigurni u identitet

osobe od koje su poruku dobili. Kao prvo, obe osobe kreiraju par komplementarnih ključeva, javni i tajni ključ. Važno je naglasiti da se poznavanjem javnog ključa ne može izračunati tajni ključ u nekom razumnom vremenu (vreme potrebno za izračunavanje tajnog ključa iz poznatog javnog ključa, tj. razbijanje šifre, meri se milionima godina na danas najjačim raspoloživim računarima). Nakon kreiranja ključeva, osobe A i B razmenjuju svoje javne ključeve, a potom pošiljalac (A), koristi svoj tajni ključ za šifriranje sažetka poruke koji je izračunao nekom od «Hash» funkcija. Hash funkcija je funkcija koja iz zadane poruke (podataka) računa sažetak fiksne dužine, obično od 128 do 256 bita. Kada primalac (B) uspe dešifrovati sažetak poruke javnim ključem pošiljaoca (A), on još računa i sažetak primljene poruke koji potom upoređuje s upravo dešifrovanim, i ako je izračunati sažetak jednak onom dešifrovanom, primalac može biti siguran u poreklo poruke (podataka), jer je poruka mogla biti šifrovana jedino tajnim ključem pošiljaoca (A), kao i u integritet poruke.

U celoj proceduri samo je jedna stvar slaba karika. Moramo biti apsolutno sigurni da javni ključ za koji mislimo da pripada pošiljaocu (A) zaista i pripada pošiljaocu (A). Naime, ukoliko primalac (B) ima javni ključ pošiljaoca (C), a veruje da ključ pripada pošiljaocu (A), tada je pošiljalac (C) u mogućnosti da krivotvori podatke pošiljaoca (A).


V01.2009

Page 50

3.7.3 ULOGA POVERLJIVE STRANKE I POTPISIVANJE JAVNOG KLJUČA Opisani problem rešava se na način da se uvodi „poverljiva stranka“, PS (engl. „trusted authority“). Pretpostavka je

da poverljivoj stranci sve ostale stranke veruju, te da svoje javne ključeve lično odnesu na potpisivanje, s tim da im PS prethodno proveri uobičajene „fizičke“ dokumente. U tom slučaju PS koristi svoj tajni ključ (javni ključ PS svima je poznat) za potpisivanje javnog ključa te time garantuje svima ostalima ispravnost potpisanog javnog ključa.

Postoji i druga mogućnost, a to je da PS svima generiše par ključeva, te uz prethodnu fizičku autentifikaciju, dodeljuje ključeve. U tom slučaju svako ko bi hteo proveriti ispravnost potpisa osobe (O) morao bi u bazi javnih ključeva (koju čuva PS) pronaći javni ključ osobe (O) i potom tim ključem pokušati dešifrovati primljene podatke. Nedostatak ovog drugog modela je taj što u tom slučaju PS poseduje i tajne ključeve što predstavlja znatan sigurnosni problem ako se isti par ključeva koristi osim za potpisivanje i za šifrovanje podataka.

Kao logičan izbor za PS nameću se državne ustanove, sudovi i javni beležnici, iako su trenutno jedine takve ustanove firme poput „Twawte“ i „Verisign“ koje izdaju certifikate potrebne firmama koje žele svojim klijentima da osiguraju sigurnu vezu prema svom web poslužitelju SSL protokolom.

Osim modela jedne centralne «poverljive osobe» postoji i neka vrsta hijerarhijskog modela (korišten u sastavu PGP), kod kojeg je svaki korisnik u mogućnosti da potpiše javne ključeve drugih osoba (za koje je siguran da pripadaju pravim osobama) te time garantovati drugima, koji su sigurni u ispravnost njegovog javnog ključa, ispravnost potpisanih ključeva.

3.7.4 Funkcija za sažimanje – hash funkcija Šifrovanje samo po sebi ne štiti integritet poruke, čak i ako ključ nije otkriven. Nužno je razviti tehniku koja će

snažno štititi integritet podataka tj. garantovati autentičnost sadržaja poruke. U tom cilju koristi se funkcija za sažimanje -hash funkcija.

Spomenućemo tzv. SHA-1 (Sesure Hash Algoritam). Ona svaku poruku, svaki tekst (predmet šifrovanja) bez obzira na njegovu veličinu, bukvalno samelje (to joj i sam naziv kaže), kao u mašini, tako da na izlazu dobijemo niz od 160 nula i jedinica. Poznato je da takvih nizova ima 2160, a koliko je to ogroman broj o tome ne treba trošiti reči.

Bitno je istaći da je računski nemoguće naći bilo koji ulaz čija je hash vrednost unapred zadati izlaz, a takođe je računski nemoguće naći dva različita ulaza sa istom hash vrednošću.

Dakle kao što je teško a možda i nemoguće naći dva čoveka sa istim otiskom prsta tako bi i falsifikatoru bilo teško da nađe dve poruke sa istom hash vrednošću.

Verovatnoća da u poruci neko izmeni neku stavku, tako da novodobiveni tekst ima istu hash vrednost kao i originalni je 1/2160=0.00000… , dakle zanemarljivo mala verovatnoća.

Kako nam Hash funkcija pomaže da utvrdimo autentičnost poruke ?

Primalac poruke će poređenjem hash vrednosti koju je primio sa digitalno potpisanom porukom i hash vrednosti koju je sam generisao nakon prijema poruke utvrditi da li je poruka ostala autentična. Ako su Hash vrednosti iste poruka nije menjana.

Primetili ste da je stvar sa pamćenjem hash vrednosti uprošćena uvođenjem heksadecimalnih brojeva. Da su ljudi imali po osam prstiju na ruci (ukupno 16) oni bi, podsetimo se, brojali na sledeći način:

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11, 12, 13, …

zbog toga mi 0 zamenjujemo sa 0000, 1 sa 0001,…,f sa 1111

Naš niz od 160 nula i jedinica delimo na grupe po četiri i za svaku tu grupu vidimo kojoj heksadecimalnoj cifri odgovara (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f), tako da pamtimo i dostavljamo primaocu samo 40 simbola, čime je posao znatno olakšan.

3.7.5 Digitalni potpis „Digitalni potpis (eng. Digital Signature) predstavlja postupak kojim se određeni segment bloka podataka, ili

standardizovane poruke, kriptografski obeležava potpisnikovim tajnim parametrom.“ Digitalni potpis je 51-bitni broj koji se dobija primenom RSA algoritma na HASH vrednost generisanu iz bloka podataka koji se štiti. On se dodaje na kraj bloka podataka koji se šalje. Pod blokom podataka misli se na čitav DER (Datoteka za elektronsku razmenu podataka) osim njegovog poslednjeg dela. Digitalni potpis i digitalno potpisani dokumenat se mogu izraziti formulom:

Digitalni potpis = E [H(m), SA]

Digitalno potpisani dokument = m; E [H(m), SA] gde su:

m - digitalni dokument koji se potpisuje,


V01.2009

Page 51

H(m) - otisak digitalnog dokumenta, a H funkcija sažetka,

SA – tajni (privatni) ključ potpisnika,

E - funkcija šifrovanja (asimetrično kriptovanje).

Kreiranje digitalnog potpisa Postupak kreiranja digitalnog potpisa se sastoji iz dve faze:

• u prvoj fazi se primenom odgovarajuće kriptografske kompresione funkcije (MD5 HASH) određuje otisak poruke (message digest),

• u drugoj fazi potpisnik poruke šifruje dobijeni otisak svojim tajnim (privatnim) ključem, primenom odgovarajućeg asimetrinog algoritma (RSA). Šifrovani otisak poruke predstavlja njen digitalni potpis i pridružuje joj se.

Slika 3.24 Kreiranje digitalnog potpisa (primer za MD5 HASH alogoritam i RSA algoritam)

Da bi potpisao dokument, potpisnik mora jasno naznačiti granice dokumenta koji potpisuje. Za označenu poruku (podatak) koji treba sigurno preneti, HASH funkcija softvera potpisnika izračunava jedinstveni otisak (message digest), pridružen jedino toj poruci.

Softver zatim transformiše otisak u digitalni potpis koristeći se potpisnikovim tajnim (privatnim) ključem. Tako nastali digitalni potpis je stoga jedinstven i za poruku i za privatni ključ koji ga je kreirao.

Uobičajeno je da se digitalni potpis pridodaje poruci, skladišti i šalje zajedno s njom. Medutim, on se može poslati i kao odvojeni podatak, dokle god zadržava pouzdanu vezu s originalnom porukom. Kako je svaki potpis jedinstveno vezan uz original, besmisleno ga je u potpunosti odvojiti od izvora na osnovu kojeg je nastao.

Verifikacija digitalnog potpisa Postupak verifikacije digitalnog postupka sastoji se iz 3 faze:

• u prvoj fazi se iz dobijene poruke izdvaja digitalni potpis i dešifruje javnim ključem pošiljaoca

• u drugoj fazi primalac kreira otisak informacionog dela dobijene poruke identičnim postupkom kao na predajnoj strani

• u trećoj fazi vrši se poređenje, i ako je dobijeni otisak poruke identičan sa dešifrovanim otiskom, verifikacija je uspešna.


V01.2009

Page 52

Slika 3.25 Verifikacija digitalnog potpisa

Funkcionalnost digitalnog potpisa Na osnovu iznetog može se zaključiti da je za funkcionalnost digitalnog potpisa potrebno izvršiti dva procesa, od

kojih jedan sprovodi potpisnik, a drugi primalac.

Uspešnom proverom digitalnog potpisa garantuje se:

• Autentičnost, pouzdanost identiteta pošiljaoca je posledica činjenice da je otisak poruke koji je šifrovan tajnim ključem, moguće uspešno dešifrovati samo primenom odgovarajućeg javnog ključa. Digitalni potpisi se mogu koristiti da odrede poreklo poruke, od koje osobe dolazi. Kada je vlasništvo tajnog ključa digitalnog potpisa vezano za određenog korisnika, pravilan digitalni potpis pokazuje da je poruka poslata od strane konkretne osobe. Važnost poverenja u autentičnost pošiljaoca poruke je naročito očigledna u oblasti finansija. Na primer, pretpostavimo da ogranak neke banke šalje uputstva centralnoj banci zahtevajući promenu na nekom računu. Ako centralna banka nije ubeđena da je takva poruka stvarno poslata iz tog ogranka, postupajući na osnovu takvog zahteva može dovesti do velike greške.

• Integritet, upoređivanjem izračunatog i dešifrovanog otiska poruke utvrđuje se da poruka nije modifikovana. U mnogo slučajeva pošiljalac i primalac poruke moraju imati međusobno poverenje da poruka nije menjana tokom slanja. Mada se enkripcijom skriva sadržaj poruke, moguće je slučajno izmeniti dekriptovanu poruku bez razumevanja šta je stvarno promenjeno (neki enkripcijski algoritmi ovo sprečavaju). U svakom slučaju, ako je poruka digitalno potpisana, svaka promena poruke će promeniti potpis. Ne postoji efikasan način da se poruka i njen potpis izmene i da se stvori nova poruka sa valjanim potpisom.

• Neporecivost, pošiljalac ne može da porekne slanje poruke pošto je potpisana njegovim tajnim ključem.

Važno je pomenuti da elektronski potpisi uopšte, pa tako ni digitalni potpis ne pružaju zaštitu tajnosti podataka od neovlašćenog čitanja, jer se svi podaci šalju u svom originalnom (nepromenjenom) obliku.

Postupci kreiranja i verifikacije digitalnog potpisa prolaze kroz postupke modifikacije već čitavu deceniju, i mogu se automatizovati do te mere da je ljudska interakcija potrebna samo u izuzetnim slučajevima. Verovatnoća otkaza ili problem sigurnosti u sistemima kriptografije koji su dizajnirani i implementirani prema razvijenim industrijskim standardima je beznačajan, i puno je manji od rizika neprimećenog falsifikata ili izmene dokumenta na papiru.

3.7.6 Digitalni sertifikat Kreiranje digitalnog potpisa i njegova verifikacija vrše se, kako je već pomenuto, asimetričnim kriptografskim

sistemom, prilikom čega se koriste:

• - tajni (privatni) ključ poznat jedino potpisniku

• - javni ključ poznat širem krugu, a ne samo primaocu.

Međutim, kako možemo biti sigurni da je to zaista javni ključ potpisnika? Rešenje ovog problema postiže se upotrebom digitalnog sertifikata. Digitalni certifikat je digitalno potpisani dokument koji povezuje javni ključ s osobom kojoj pripada. Možemo ga nazvati i digitalnom ličnom kartom, jer on to zaista i jeste - digitalna lična karta u ”cyber prostoru”, odnosno sredstvo kojim dokazujemo identitet na Internetu.

”Digitalni sertifikat (eng. Digital Certificate) predstavlja element kojim se utvrđuje veza između identiteta subjekta i njegovog javnog ključa primenjenog asimetričnog algoritma”.


V01.2009

Page 53

Elementi koji čine strukturu digitalnog certifikata su:

• verzija formata sertifikata - sadrži oznaku strukture digitalnog sertifikata. Jedan od najzastupljenijih formata digitalnih sertifikata definisan je X.509 standardom.

• serijski broj sertifikata - sadrži vrednost koju dodeljuje sertifikacioni autoritet u trenutku kreiranja digitalnog sertifikata

• identifikator algoritma - sadrži podatke o algoritmu koji je primenjen za digitalno potpisivanje

• naziv sertifikacionog tela - identifikuje izdavača digitalnog sertfikata

• rok važnosti sertifikata - sadrži vremenski period u kome je izdati digitalni sertifikat validan

• vlasnik sertifikata – predstavljen je složenom strukturom koja obuhvata nekoliko ličnih podataka:

• dvoslovni niz koji označava državu

• region u okviru države

• elektronska adresa (e-mail)

• naziv mesta u kome stanuje

• naziv organizacije u kojoj je zaposlen

• ime vlasnika,

• naziv odeljenja (niže organizacione celine) u organizaciji

• ime vlasnika sertifikata

• polje dodatnih atributa - sadrži vrednosti koje identifikuju vlasnika sertifikata a nisu sadržane u polju vlasnik sertifikata (broj telefona, broj faxa itd.)

• informacija o javnom ključu vlasnika – sadrži javni ključ i identifikator asimetričnog algoritma sa kojim se dati ključ primenjuje

• digitalni potpis sertifikata - od strane ustanove koja je izdala setifikat (CA).

Slika 3.26 Struktura digitalnog sertifikata

Prema dosadašnjim iskustvima ovakva struktura sertifikata ispunjava zahteve savremenih kriptografkih sistema zaštite. Većina savremenih sistema zaštite, koji uključuju infrastrukturu sa javnim ključevima (PKI), bazira se na primeni X.509 digitalnih sertifikata.


V01.2009

Page 54

Uloga digitalnog sertifikata je da dovede u jednoznačnu vezu fizički identitet subjekta sa njegovim javnim ključem.

Kreiranje i digitalno potpisivanje sertifikata vrši “treća strana od poverenja” (eng. Trusted Tthird Party, TTP). Ukoliko prijemna strana uspešno verifikuje dobijeni sertifikat, onda je ona sigurna u autentičnost pošiljaoca poruke – vlasnika odgovarajućeg tajnog ključa. Kako je par ključeva matematički povezan, ako je asimetrični sistem dobro oblikovan i implementiran, nemoguće je iz javnog ključa izdvojiti tajni (privatni) ključ. Stoga, bez obzira na to što je javni ključ poznat mnogima, u svrhu potvrde identiteta potpisnika, nemoguće je otkriti njegov tajni ključ i iskoristiti ga za lažiranje digitalnog potpisa. Ova činjenica se naziva načelo ireverzibilnosti.

Digitalni sertifikati mogu biti:

• samopotpisani i

• kvalifikovani.

Samopotpisane digitalne sertifikate može da izda „bilo ko”, pa čak i sam korisnik. Uglavnom se koriste interno, a „pravna snaga“ dobija se potpisivanjem posebnog ugovora sa korisnikom (npr. e-banking sistemi).

Kvalifikovane digitalne sertifikate može da izda samo sertifikaciono telo koje ispunjava određene zakonske uslove i ima dozvolu za rad, što je definisano Zakonom o digitalnom potpisu i pripadajućim podzakonskim aktima. Kvalifikovani digitalni sertifikat sa odgovarajućim parom ključeva može se upotrebiti za kreiranje „kvalifikovanog digitalnog potpisa“ elektronskog dokumenta, koji je po pravnoj snazi ekvivalentan papirnom dokumentu potpisanom i overenom na klasičan način – olovkom i pečatom.

3.7.7 Digitalni potpis: zaključak Zakonske regulative (zemalja koje imaju zakon o digitalnom potpisu) ne određuju niti jednu tehnologiju potpisivanja

kao dominantnu, već samo donose propise kojih se svaka od tehnologija mora pridržavati. Kao prvo, od digitalnog se potpisa očekuje da bude jedinstven osobi koja ga koristi, drugo, da se može proveriti kome pripada odnosno da li zaista pripada osobi koja ga je koristila, treće, da je u potpunoj kontroli osobe koja ga koristi, četvrto, da potvrđuje i sebe i podatke koje potpisuje.

Već iz ovog vidimo da postoji znatna prednost digitalnog potpisa nad klasičnim metodama autentifikacije. Najveća prednost je ta što se valjanost potpisa proverava svaki put pri prijemu dokumenta, za razliku od klasičnih potpisa koji se proveravaju tek na sudu, kad se prevara već odigrala. Osim ove prednosti postoji još jedna značajna prednost, a to je nemogućnost naknadne izmene potpisanog dokumenta, kao i nemogućnost potpisivanja praznih dokumenata. Ipak, ukoliko krivotvoritelj uspe da dođe do tajnog ključa, tada bez ikakvih problema može falsifikovati podatke bez da postoji i najmanja mogućnost utvrđivanja različitosti takvog potpisa od pravog potpisa, što kod klasičnih metoda ipak nije slučaj.

Nemali broj kriptografskih algoritama zaštićen je različitim patentima. Tako je npr. najrašireniji asimetrični kriptografski algoritam, RSA, bio patentiran 17 godina sve do 2000. godine, a drugom isto tako vrlo značajnom protokolu, Diffie-Hellman protokolu, patent je istekao 1997. godine. Nažalost, ovo nisu jedini takvi primeri kao ni jedini problemi u široj primeni kriptografskih algoritama. Proizvođači kriptografskog softvera (bili) su prisiljeni da proizvode po dve ili čak tri različite verzije istog softverskog paketa da bi se udovoljilo svim izvoznim i patentnim regulativama; zabrana izvoza kriptografskog softvera iz SAD-a s ključem dužim od 40-bita bila je na snazi do pred kraj 1999. godine, tako da je npr. NAI («Network Associates») bio prisiljen da ima dve verzije svog programa PGP, jednu za tržište SAD-a a drugu za internacionalno tržište. Ipak, obe su verzije koristile «jaku» enkripciju tako što je iskorišćena «rupa» u zakonu SAD-a kojim se zabranjuje izvoz softvera u binarnom obliku ali ne i izvornog koda na papiru??? Osim ovog, postojao je i problem zbog patentiranog RSA algoritma, tako da verzije za SAD nisu koristile istu skraćenicu kao i internacionalne.

Sličan problem javlja se i s pojavom novog američkog standarda za digitalno potpisivivanje («Digital Signature Standard», DSS, 1994), jer se delovi korišćenog algoritma (koji sam po sebi nije patentiran) nalaze pod patentnom zaštitom autora sličnog algoritma temeljenog na diskretnim logaritmima (Schorr, 1994, patent vredi 17 godina). Ovaj primer ipak odskače iz mnoštva drugih upravo zbog toga što se radi o standardu koji su obavezne koristiti sve državne ustanove SAD-a; drugim rečima ovaj će patent vrlo verovatno američki porezni obveznici osetiti na vlastitom džepu.

Na kraju spomenimo još i zabranu izvoza bilo kakvog kriptografskog softvera zemljama poput Iraka, Severne Koreje ili Kube.


V01.2009

Page 55

4. Ne kriptografske tehnike zaštite poverljivosti informacija 4.1. Mehanizmi kontrole pristupa : Tokeni

4.1.1 Evolucija potrebe za autentifikacionim tokenima Pristup resursima Informacionh sistema preduzeća i ustanova koristeći računarske mreže i internet otvorio je novi

svet mogućnosti za Internet poduhvate. Danas, korisnici mogu pristupiti njihovoj zajedničkoj mreži iz hotelske sobe ili kafića u gotovo svakom gradu na svetu. Mrežni administratori sada mogu upravljati čitavom mrežom preduzeća iz udobnosti svojih domova, više ne moraju da se vraćaju do kancelarije u 03:00 časova ujutru da bi obavili neki kritičan zadatak. Tanka klijent tehnologija i stvarni privatni mrežni pristup su omogućili da se može pristupiti čitavoj mreži preduzeća bilo kada i bilo gde.

Sa pogodnošću i dodatnom produktivnošću priuštenom od strane daljinskog pristupa dolazi i mnogo velika količina rizika: Keylogger malware lukavo instaliran na 14 javnih Internet terminala u Manhattan-u dozvoljavao je napadačima da kompromituju personalne informacije i pristupe mreži hiljadama ljudi i organizacija. Jedna Silicon Valley kompanija trpela je mesece neautorizovanog pristupa od strane prestupnika pre nego što su otkrili prodor bezbednosti. 2006.-te, dobro organizovan kradljivac identiteta orobio je preko 300 korisnika dobro-poznate finansijske institucije, praveći trošak toj instituciji preko 3 miliona dolara čistog gubitaka. Phishers vrše zarazu Internet-a na dnevnim bazama, koristeći njihove društveno tehničke smicalice da skupljaju korisnička akreditivna pisma za bankarstvo i E-commerce mušterije, dozvoljavajući im da brzo i tiho crpe korisničke račune.

Koren problema je u većini slučaja krađa lozinke ili passworda.

Prosečan kompijuterski korisnik ima gomilu računa online kao i na poslu. Pristup gotovo svim ovim sistemima zahteva password. Većina ljudi ne može zapamtiti različiti password za svaki njihov račun, naročito ako određenim aplikacijama pristupaju samo jednom mesečno. Evo nekoliko načina na koje se prosečni korisnici bore sa svojim problemima pamćenja:

1. Biraju jednu šifru za sve. Naravno, ako je njihov password za njihovu ličnu Web poštu kompromitovan, dobre su šanse da je takođe kompromitovan i password mreže koji koriste na poslu.

2. Zapisuju svoje password-e. Jedna online studija je otkrila da preko 30 posto anketiranih ljudi zapisuje na papir svoje password-e i krije ih ispod tastature, na heftalice ili u fiokama svoga stola.

3. Biraju informaciju koju mogu lako zapamtiti. Mnogo ljudi – čak do 35 posto prema nekim ekspertima – bira neki deo lične informacije: ime člana porodice ili kućnog ljubimca ili datum rođenja. Problem je što je takva informacija često opšte znanje. Potencionalni haker može u hodniku proćaskati sa zaposlenim – i doći do gomile password-a koje bi mogao da proba.

4. Postanu pametniji. U bilansu password-a jedne kompanije, 10 posto password-a su bili ’’stud’’, ’’goddess’’, ’’cutiepie’’ ili neki drugi uobraženi password. Još više uznemiravajuće, 12 posto password-a su reč ’’password ’’ – i mnogo korisnika koji su je izabrali su pomislili da je to lukav izbor. Problem je što hakeri znaju sve ovo. Pre nego što probaju personalnu informaciju da slome password, prva stvar koju će probati je ’’password’’. Hakeri će se takođe pretvarati da rade u kompaniji, koračati samouvereno kroz glavna vrata sa klimom glave recepcionaru ili obezbeđenju. Bilo koji password-i na monitoru ili ispod tastature su fer igra. Kada haker jednom slomi password, može videti poverljiva dokumenta ili e-mails a da organizacije to nikada ne saznaju.

4.1.2 Password-cracking alati su takođe evoluirali Tradicionalni brute-force password-cracking alati pretražujući kroz liste poznatih password-a ili automatski

pokušavajući svako slovo, broj i simbol u password nagađanjem generisanom od strane mašine više nisu primarni alati za krekovanje korisničkih password-a ne bi li se dobio privilegovan pristup. Tradicionalni brute-force password cracker je evoluirao da bi uključivao korišćenje precomputed password hashes. Tabele duge – skup algoritma koji mogu biti download-ovani – dozvoljavaju zlonamernom hakeru da preračuna svaku kombinaciju brojeva slova i simbola u raznim password dužinama. Jednom kad je komplet tabela proračunat, pogađanje password-a više nije potrebno; samo se jednostavno potraži u precomputed hash bazi podataka.

4.1.3 Jaka autentifikacija umanjuje rizik od slabih password-a Odgovor na ovaj ogroman problem je jaka autentifikacija. Ovo se odnosi na faktore koji rade u kombinaciji da zaštite

resors. Automatic teller machines (ATM) su najobičniji primer ovoga: da bi pristupili njihovom čekovnom računu, mušterije moraju iskoristiti dva faktora da bi bili autorizovani. Prvo, moraju imati svoju čvrstu bankovnu karticu (prvi faktor: šta imaš),


V01.2009

Page 56

drugo, moraju znati njihov personalni indetifikacioni broj (PIN) (drugi faktor: šta znaš). Većina ljudi ne bi želela da se njihov čekovni račun čuva samo sa PIN-om ili samo sa karticom – i pored toga kompanije koriste password-only zaštitu da čuvaju resorse koji su mnogo više puta vredniji od čekovnog računa prosečne osobe. Državni standardi sada čine imperativom zaštitu potrošačkih informacija. Naročito agencije za brigu o zdravlju i finansijske institucije shvataju da je implementacija jake autentičnosti korak napred ispunjenju skoro donešenih zakona da bi se zaštitili pacijenti i klijenti.

Ne shvatajući to, mnoge organizacije su koristile jake autentičnosti već godinama: zaposleni su morali da znaju password-e da bi pristupili kompanijinoj mreži (prvi faktor: šta znaš), ali su takođe i morali da budu u njenoj zgradi (drugi faktor: gde si). Ali daljinski pristup je oduzeo zahteve lokacije, kao što je zahtevalo današnje poslovno okruženje, a kao rezultat autentifikacija je postala ranljiva.

4.1.4 Tokeni su dobri kandidati za jaku autentifikaciju Tokeni su mali komadi hardwire-a, oko pola veličine kreditne kartice (ali malo deblji), koji obično staju na privezak

za ključeve. Kao ATM kartica, ovaj faktor je ’’šta imaš’’. Obično imaju ekrane od tečnog kristala i daju korisniku onetime passcode za svaki log-in. Umesto log-ovanja sa password-om, korisnik aktivira token i ukuca karaktere sa ekrana tokena na polje za password. Tokeni obično zahtevaju deo software-skog servera koji dozvoljava ili odbija pristup korisniku. Velika prednost za većinu odeljenja informacionih tehnologija je da token rešenja ne zahtevaju deo clien software-a na korisničkoj mašini. Tokeni, zbog toga, mogu da se koriste svuda: na javnim Internet terminalima, na Web-u, sa bilo kog laptop-a, desktop-a ili palmtop-a. Neki korisnici inicijalno odbijaju tokene, a neke kompanije su zabrinute zbog cene: 70 dolara po korisniku je previše za početnu cenu mnogih rešenja. Ali rešenje je cost-competitive, visoko pouzdano, prenosivo a i jedno je od najjednostavnijih opcija dostupnih za razvijanje.

Slika 4.1 Vrste i izgled tokena

4.1.5 Podela tokena na tipove Sadašnja generacija tokena je dostupna u oblicima koji su mnogo manje nametljivi korisnicima od tokena predhodne

generacije. Danas skoro sve implementacije tokena koriste jednovremenske password metodologije. Kao efekat, password se menja posle svake autentifikacione sesije. Ovo efikasno smanjuje rizik od gledanja preko ramena i njuškanja za password-om, jer je on validan samo za jednu sesiju i vise se ne može ponovo iskoristiti.

Asinhroni tokeni Asinhroni tokeni, takođe zvani tokeni bazirani na događaju ili odgovoru na izazov, dostavljaju novi jednovremenski

password svakom upotrebom tokena. Iako može biti konfigurisan da istekne na određen datum, njegov životni vek zavisi od toga koliko se često koristi. Token može trajati od 5 do 10 godina i efikasno produžiti vreme tipično korišćeno u kalkulaciji totalne cene posedovanja pri razvijanju višefaktorne autentičnosti. Pri korišćenju asinhronog tokena sa jednovremenskim password-om subjekat access kontrole tipično ižvršava petostepeni proces da autentifikuje svoj identitet i dobije slobodan pristup:

1. Autentifikacioni server dodeli zahtev za upit subjektu access kontrole.

2. Subjekat access kontrole unese upit u njen ili njegov token uređaj.

3. Token uređaj matematički izračuna tačan odgovor na upit autentifikacionog servera.


V01.2009

Page 57

4. Subjekat access kontrole unosi odgovor na upit zajedno sa password-om ili PIN-om.

5. Odgovor i password ili PIN budu verifikovani od strane servera za autentičnost i, ako je sve u redu, pristup je dozvoljen.

Sinhroni tokeni Sinhroni tokeni, takođe znani kao tokeni bazirani na vremenu, koristi vreme u proračunavanju jednovremenskog

password-a. Vreme je sinhronizovano između token uređaja i autentifikacionog servera. Vrednost trenutnog vremena je šifrovana zajedno sa tajnim ključem na token uređaju i dostavljena je subjektu access kontrole za autentifikaciju. Tipičan sihroni token pruža novi kod sastavljen od 6 do 8 cifara svakih 60 sekundi; može raditi do 4 godine i može biti programiran da prestane sa radom na predodređeni datum. Sinhroni token zahteva manje koraka za subjekta access kontrole, pa da bi se izvršila autentifikacija mora uspešno proći sledeće:

1. Subjekat access kontrole čita vrednost sa njenog ili njegovog token uređaja.

2. Subjekat access kontrole unosi vrednost sa token uređaja u log-in prozor zajedno sa njenim ili njegovim PIN-om.

3. Server za autentifikaciju izračuna svoju komparativnu vrednost baziranu na vrednosti sinhronizovanog vremena i PIN-a subjekta access kontrole. Ako se komparativne vrednosti slažu, pristup je dozvoljen.

Upotreba PIN-a zajedno sa vrednošću dobijenom od tokena pomaže smanjenju rizika od gubljenja i krađe i njegove upotrebe

od strane neautorizovane osobe da dobije pristup kroz sistem access kontrole.

4.1.6 Probijanje tokena Od kako su tokeni postali najpopularnija alternativa za tradicionalne password-e samo jedna metodologija napada je

bila uspešna u stvarnosti da ih slomi i to je uspešno korišćena protiv samo jednog token vendora. Hakeri su napravili obratnu metodologiju korišćenu u proračunima za jednovremenske password-e i koristeći to, u kombinaciji sa serijskim brojem i aktivacionim ključem tokena, mogli su da izračunaju sledećih 8 jednovremenskih password-a koji bi bili izračunati od strane tokena. Ova metodologija je bila implementirana u popularni Cain & Abel password-cracking tool v2.5 beta 21 (slika 3.2) nađen na http://www.oxit.it/ i bio je smanjen čuvanjem aktivacionog ključa odvojeno i sigurno dok vendor nije predstavio novu verziju tokena koristeći drugačiju metodologiju jednovremenskog password računanja.

Slika 4.2 Cain & Abel password-cracking tool


V01.2009

Page 58

Tokeni su otporni na napad, ali loše implementacije tokena mogu proizvesti slabosti koje hakeri mogu da pretvore u svoju korist. Nedavno, koliko 2006. god., man-in-the-middle (MITM) attack (slika 3.3) je bio uspešan u kompromitaciji implementacije tokena za poznatu banku. Iako se napad oslanjao jedino na social engineering i nije iskoristio slabost samog tokena važno je da se razmotri metodologija ovog napada pri razvijanju bilo koje token implementacije. Jedna metodologija smanjenja rizika za ovaj napad koji dobija na popularnosti je razmatranje reputacije (slika 3.4) Internet Protocol adresa, mreža ili područja sa kojih je zahtevana autentifikacija. Odbijanjem autentifikacije sa izvora koji ima ’’lošu reputaciju’’ može biti priušteno značajno smanjenje rizika prilikom razmatranja MITM napada.

Slika 4.3 Man-in-the-middle napad

Trenutna razvojna rešenja u identity and access management (IAM) takođe obezbeđuju jake implementacije tokena uzimajući u razmatranje sigurnost zadnje tačke (endpoint) sa koje korisnik vrši autentifikaciju. Uobičeno je da u trenutnoj generaciji ponuda IAM produkta se ceni sledeće:

• The endpoint pušta u rad zahtevan antivirus software i signatures su up to date.

• The endpoint pušta u rad zahtevan firewall i konfiguracija odgovara zahtevima konfiguracije sigurnosti enterprise endpoint-a.

• The endpoint operativni sistem je patch-ovan do trenutnih nivoa.

• The endpoint aplikacije su patch-ovane do trenutnih nivoa.


V01.2009

Page 59

Slika 4.4 Reputation defenses

Ako je zadnja tačka nepopustljiva, pristup je odbijen i korisnik je ograničen na oblast mreže gde može ispraviti predhodne greške da bi mu se ponovo dozvolilo da izvrši autentifikaciju na enterprise network za dozvoljeni privilegovan pristup.

Na kraju, autentifikacioni tokeni jednovremenskog password-a današnje generacije od strane samih sebe mogu preći dalek put prema smanjenju rizika povezanih sa tradicionalnim password-ima. Bilo kako bilo, da bi priuštili maksimalno smanjenje rizika prema enterprise-u, treba razmotriti autentifikacione tokene kombinovane sa sistemima access kontrole koji koriste ocenjivanje reputacije ili potvrdu sigurnosti zadnje tačke, sa koje korisnik treba da se autentifikuje.

4.1.7 Autentifikacija i uloga tokena Autentifikacija je važan deo svakog sistema ili sigurnosti aplikacija. To je temelj svake access kontrole koja je

potrebna nad informacijom koja se nalazi u sistemu ili autorizaciji bilo kojih transakcija koje bi se mogle izvršiti. Da bi se obezbedila jača autentifikacija tokeni se sve više koriste da bi dodali dodatnu dimenziju ili faktor autentifikacije ne bi li smanjili rizik zarobljavanja korisnika od strane napadača.

Generalno postoje 3 različita faktora koja se koriste u autentifikaciji korisnika. Ovi faktori su nešto što znaš, kao password; nešto što imaš, što bi moglo biti token uređaj; i nešto što jesi, što može biti implementirano kroz biometrics kao što je otisak prstiju ili neke druge fizičke karakteristike. Ovo poglavlje će dati pregled procesa autentičnosti, korišćenje različitih faktora autentičnosti da bi se ustanovio identitet kao i neke rizike vezane za korišćenje različitih faktora autentifikacije i način na koji tokeni mogu biti iskorišćeni da bi smanjili te rizike.

Pregled faktora koji utiču na autentifikaciju Autentifikacija predstavlja nečiji pokušaj uspostavljanja identiteta pod kojim su objavili da se nalaze. U svetu

kompijutera primer koji je preovladao je kad korisnici vrše autentifikaciju treba da dokažu da oni jesu osobe kojima je dodeljen specijalni ID koji se koristi za kontrolu pristupa sistemu. Postoje 3 vrste faktora autentifikacije. Ova 3 faktora su nešto što znaš, nešto što imaš i nešto što jesi. Oni se mogu koristiti odvojeno ili zajedno da bi autentifikovali identitet.

Prvi faktor, ’’nešto što znaš’’, takođe zvano javna tajna, je generalno implementirano kao statičan password koji je deljen između osobe koju treba autentifikovati i servera koji autentifikuje access (slika 3.5). Proces autentifikacije obično počinje korisnikovim ukucavanjem password-a na client. Password se onda šalje na server za autentifikaciju gde se stavlja na one-way hash algoritam da bi se generisao hash za password. Hash algoritam ima svojstvo da generiše jedinstven hash za različite password-e, ali mu je nemoguće da rekonstuiše password od hash vrednosti. Taj hash se onda upoređuje sa hash-om koji se nalazi na serveru za autentifikaciju da bi se videlo da li se poklapaju. U nekim implementacijama hash se generiše na


V01.2009

Page 60

client-u pre nego što je poslat serveru. Postoje brojni načini da se napadne ovaj metod autentifikacije, od kojih je jedan da se presretne password nadgledanjem ili ’’njuškanjem’’ po mreži. Šifrovanje bi se moglo iskoristiti u prevenciji presretanja password-a kada se prenosi po mreži. Većina Web portala upotrebljava implementacije sigurnog kanala od strane Hipertext Transfer Protocol-a da bi smanjili rizike pri prihvatanju informacija o autentičnosti. Još jedan metod napada je kroz upotrebu keystroke logger programa koji može biti prisutan na pozadini korisnikovog uređaja. Ovi programi mogu snimiti sve što se kuca na tastaturi, uključujuci password-e, a onda to poslati trećem licu. Keystroke loggers su korišćeni u mnogim kompijuterskim virusima da pokupe password-e koji bi mogli da se iskoriste za dalje kompromitovanje ili stvarnu krađu sa online banking-a. Instaliranjem i držanjem up to date, antivirus software će pomoći u sprečavanju ovih virusa da se instaliraju na software. Ovaj rizik se takođe može redukovati tako što se neće koristiti račun sa administratorskim privilegijama za traženje po Internet-u ili čitanje e-mail-a. Ove dve aktivnosti su najpreovladivi pravci korišćeni od strane virusa da zaraze mašinu.

Slika 4.5 Reputation defenses

Tipično ako virus pokušava da zarazi mašinu preko jednog od ovih načina, radiće kao dopuna korisniku koji obavlja akciju. Ako korisnik nema administrativan pristup mašini onda većina virusa neće moći da instalira keystroke logger. Treći način napada je onaj gde se koristi social engineering da bi se prevario krajni korisnik da dobavi kritične podatke sistemu koji je posedovan ili nadgledan od strane napadača. Ovo je obično rađeno korišćenjem phishing e-mails. Phishing e-mail je lažni e-mail koji izgleda kao da je došao sa javnog izvora. Lažni e-mail obaveštava korisnika da obezbedi svoje kritične podatke preko Web link-a koji je sadržan u e-mail-u. Web link izgleda kao da se konektuje autentičnom sistemu a u stvari pokazuje na lažni sistem koji je napravljen da izgleda kao pravi i koji je nadgledan ili vlasništvo napadača. Ovi napadi su postali sve više i više sofisticirani i mogu biti uspešni čak i ako veoma mali procenat korisnika odgovori na e-mail zbog velike brojnosti poslatih. Umanjivati ove napade je veoma teško pošto zavisi od modifikacije ponašanja korisnika tako da ne veruju link-ovima poslatim e-mail-om. Zato što ovi napadi zavise od korisničke svesnosti o njima, nastaviće da budu uspešni u sakupljanju password-a od korisnika koji nisu svesni napada na ovaj način.

Još jedan od metoda napada na statične password-e je pokušaj svake moguće kombinacije password-a da bi se utvrdio tačan password. Ovaj metod se obično naziva password-guessing ili brute-force napad. Ovo je obično rađeno hvatanjem obračunatog hash-a password-a, ili preko njuškanja mreže ili preko servera na kom se nalazi, a onda korišćenjem programa da generiše svaku moguću kombinaciju password-a, izračuna njihov hash, a onda upoređuje te hashes sa uhvaćenim hash-om dok ne dođe do onog koji se poklapa. Ovi napadi zahtevaju mnogo vremena zavisno od dužine i kompleksnosti password-a. Na primer, password koji je napravljen od 6 numeričkih cifara u rangu od 0 do 9 će imati 1 milion kombinacija


V01.2009

Page 61

koje će morati da se isprobaju, što znači da password koji je napravljen od do 6 velikih i malih alfanumeričkih karaktera će imati preko 56 biliona kombinacija. Kako bilo, sa napredovanjem u brzini procesiranja, korišćenjem kompijutera generisanje svih 56 biliona kombinacija će trajati samo par časova. Da bi se još više smanjilo vreme, specijalno za duže password implementacije, brute-force napad može biti ubrzan korišćenjem predhodno obračunatih tabela password-a i hashes-a povezanih sa njima, koji se obično zovu rainbow tables. Ako se hash password-a može nabaviti sa autentifikacionog servera ili presresti na mreži, onda se njegov odgovarajući password može potražiti u rainbow table-u za mnogo kraće vreme. Jedna vrsta zaštite od rainbow tables-a je kroz korišćenje ‘’salt’’ kao dela hash algoritma. Salt je broj bitova koji su dodati password-u pre nego što je pokrenut algoritam. Ovo efikasno produžuje password i čini svaki brute-force napad težim. Takođe, bitovi dodati salt-u mogu da ne odgovaraju nekim karakterima korišćenim za stvaranje rainbow table-a pošto mogu biti neispisivi i obično ne korišćeni u password-u. Rainbow table stvorena samo sa ispisnim karakterima na ovaj način bi postala ne efektivna.

Još jedna iplementacija faktora ’’sta znaš’’ je kroz korišćenje sigurnosnih pitanja i odgovora dobavljenih od korisnika. Ovo su pitanja i odgovori koji su registrovani između korisnika i autentifikacionog autoriteta. Oni su obično ostvareni kao deo registracionog procesa za uspostavljanje ID-a za određeni sistem. Upotreba gde preovlađuju je u procesu identifikacije korisnika koji je izgubio ili zaboravio password i zbog toga mora da ga resetuje. Ovaj proces može biti ugrožen ako pitanja koriste informacije koje se mogu dobiti kroz javnu arhivu, kao što je majčino devojačko prezime ili datum rođenja. Najbolja implementacije u ovom procesu je upotreba pitanja, a i odgovora koji su izabrani od strane korisnika iz gomile pitanja i koji ne sadrže informacije koje se lako mogu nabaviti od strane trećeg lica. Pitanja kao što su ’’koja vam je omiljena boja?’’ ili ’’za koji klub navijate?’’ su primeri pitanja koja bi se mogla upotrebiti. U praksi, više od jednog pitanja se obično upotrebljava da se potvrdi identitet individue pre nego što se obave neke akcije.

Sledeći faktor je ’’nešto što imaš’’ ili nešto što poseduješ. Ovo je obično implementirano kroz korišćenje uređaja ili tokena koji krajnji korisnik nosi sa sobom. Ovaj uređaj ili token će obezbediti autentifikacioni kod koji će se koristiti da potvrdi korisnika. U nekim implementacijama, ovaj autentifikacioni kod je kombinovan sa personalnim indetifikacionim brojem (PIN) ili drugim password-om koji korisnik zna da bi se osiguralo da uređaj ne može biti korišćen od strane neke druge osobe. U drugim iplementacijama, PIN ili password se koriste da zaključaju uređaj i time ga spreče da stvara važeće autentifikacione kodove, naravno dok se isti ne ukucaju. Kada se PIN ili password i uređaj koriste zajedno, to je poznato kao two-factor autentifikacija. Uređaji smanjuju pretnju single-factor implementacijama password-a tako što generišu autentifikacione kodove koji su onetime-use passwords. Ovi password-i se mogu koristiti samo jednom za autentifikaciju i biće odbijeni ako se pokušaju ponovo iskoristiti. Ovo poništava napade koji uključuju presretanje na mreži ili keylogging zbog dinamične prirode password-a. Napadi protiv ovakvih uređaja obično uključuju kompromitovanje komunikacionog kanala od krajnjeg korisnika do servera ili su to bukvalno fizički napadi na same uređaje u pokušaju da se kopira uređaj ili utvrde neke njegove karakteristike. Ovi sistemi uključuju povećane troškove kako na uređaje tako i za ljude koji ih koriste.

Treći faktor, ’’nešto što jesi’’ se obično implementuje preko biometričkog merenja. Najzastupljenija biometrička implementacija danas je poklapanje otisaka prstiju. Druge biometričke mere koje su istražene i imaju neke ograničene implementacije su prepoznavanje rožnjače oka, struktura šake i prepoznavanje glasa. Ovaj faktor ima prednost zato što ga je ekstremno teško ukrasti i, kao i token, obično je kombinovan sa nekim drugim faktorom da bi mu se povećala efektivnost. Postoje nedostaci implementacijama ovog faktora jer ovi sistemi stvaraju veće stope false-positives i false-negatives-a. Postoji takođe određena mera ustezanja od upotrebe nekih od ovih implementacija zbog briga da metod za merenje može prouzrokovati neku štetu. Mnoge od ovih implementacija su skupe ali čitačima otisaka prstiju i sistemima za prepoznavanje lica cena opada kako postaju sve šire dostupni i počinju da budu uključivani u deo standardne konfiguracije sistema. Generalno gledano, napadi na ovaj faktor su obično pokušaji da se prevari čitač biometričkih mera i iskoriste sve slabosti koje ima u tačnom merenju biometričkih mera. Ovo je bilo posebno tačno za neke skenere otisaka prstiju koji su bili osetljivi na lažne otiske iskalupljene od plastike ili želatina. Tehnologija biometričkih skenera uglavnom se još usavršava i dok se ne završi sa radom na greškama postojaće rizik da će moći da budu prođene tako što će dozvoljavati false-positives ili neće dozvoljavati autorizovanim korisnicima generišući false-negative.

Još jedna oblast biometričkih mera vredna pomena je kategorija zvana dynamic biometrics. Ovo je tehnologija koja pokušava da rađenjem neke akcije indentifikuje osobu. Dve koje su provladale su signature biometrics, koji meri pritisak i dinamiku potpisa nečijeg imena i keyboard dynamics, koji meri brzinu, dužinu pritiska tipke i ritam korisnika koji kuca na tastaturi. Ova tehnologija je u veoma ranom stanju razvitka i nije imala mnogo implementacija tako da je veoma malo dostupnih podataka o njenoj efikasnosti.

Jedan rastući trend u oblasti autentifikacije je korišćenje više faktora od jedne javne tajne (nešto što znaš) za autentifikaciju individue. Ovo se radi zahtevanjem ne samo password-a već takođe, u nekim slučajevima, odgovora na predetermisano pitanje. Još jedan primer može biti potreba da se dostavi password i selektuje prethodno dogovorena slika iz grupe slika za autentifikaciju. Ovo je urađeno zbog pokušaja dobijanja dodatne autentifikacione informacije koja ne bi mogla biti u posedstvu potencijalnog napadača. U nekim od ovih implementacija, ove višestruke autentifikacije se rade kada se nešto neobično desi. To se može desiti kada korisnici vrše log in sa radnog mesta sa koga to obično ne čine ili ako žele da izvrše neustaljenu akciju kao što je transfer celog bankovnog računa.


V01.2009

Page 62

Sve u svemu, dobra autentifikacija je važna kao baze access kontrole sistemima i aplikacijama. Autentifikacija korišćenjem javne tajne dolazi pod konstantan napad kroz korišćenje keyboard loggers i nadgledanje mreže koje može snimiti informacije i učiniti ih dostupnim trećem licu. Biometrička autentifikacija postaje široko dostupna ali je i dalje suočena sa nekim preprekama u korišćenju i ne može se adaptirati njeno čitanje sa većinom trenutnih aplikacija. Autentifikacija korišćenjem token uređaja koji proizvode dinamičke password-e je adaptovana za čitanje i može je koristiti većina postojećih sistema koji prihvataju password, jeftinija je od većine biometričkih sistema i može se implementirati sa PIN-om da ostvari autentifikaciju sa dva faktora. Od trenutnih metoda dostupnih za autentifikaciju, tokeni koji su korišćeni da implementiraju autentifikaciju sa dva faktora izgledaju kao najbolje rešenje’za davanje jake autentifikacije, smanjujući rizik od kompromitovanja kroz presretanje.

Vrste tokena i način na koji rade Tokeni ili uređaji koji se mogu iskoristiti za implementaciju autentifikacije sa dva faktora mogu biti grupisani u par

različitih tipova ili klasa. Ovi tipovi su time-synced uređaji koji daju autentifikacione kodove na predodređene intervale, on-demand ili asinhroni uređaji koji daju kodove kad je potrebno i kriptografski uređaji. Ovi tokeni koriste različite metode da bi dali dinamičke autentifikacione informacije. Svaki od ovih tokena imaju prednosti i mane u metodama koje upotrebljavaju.

Prva vrsta su vremenski sinhronizovani (time-synced) tokeni. Ovi tokeni koriste sinhronizovane satove između token uređaja i autentifikacionog servera da generišu kodove koji će biti iskorišćeni za autentifikaciju. Token koristi vreme na satu kao deo algoritma da generiše kod koji se periodično menja. Ovaj kod je onda prikazan korisniku i tada je ili iskorišćen kao autentifikacioni kod ili kombinovan sa PIN-om da formira autentifikacioni kod, koji autentifikuje korisnika. U nekim implementacijama PIN se unosi u uređaj i onda biva iskorišćen kao deo algoritma za generaciju autentifikacionog koda. Ovaj metod ima tu prednost što može raditi sa većinom aplikacija uz minimalnu promenu pošto autentifikacioni kod služi samo kao zamena za password koji bi bio dostavljen od strane korisnika. Jedan nedostatak koji imaju ovi tipovi tokena je da će satovi vremenom pomalo odstupati što će na kraju dovesti do nestanka sinhronizacije između servera i uređaja. Ovo može zahtevati da tokeni budu periodično resinhronizovani zajedno sa serverima ako odstupanje bude preveliko. Veoma je važno da server takođe održava tačno vreme. Obično, ovo se radi korišćenjem protokola mrežnog vremena koji koristi dosledan vremenski server ne bi li se osiguralo tačno čuvanje vremena. Autentifikacioni proces na serveru će takođe pokušati da izmeri vremensko odstupanje između svog sata i sata na tokenu i prema tome podesi svoj autentifikacioni proces. U nekim implementacijama autentifikacioni proces će koristiti autentifikacioni prozor, koji će prihvatiti radijus autentifikacionih kodova koji će biti dobri za predefinisan period vremena. Ovo će sprečiti višak odbijenih autentifikacija zbog odstupanja sata između autentifikacionog servera i tokena ali takođe povećati broj autentifikacionih kodova koji će biti prihvaćeni. Zavisno od veličine upotrebljenog prozora, što povećava rizik da bi napadač mogao da pogodi autentifikacioni kod, broj mogućih kodova je obično toliko veliki da je ovaj rizik prilično mali. Ovi tokeni takođe mogu predstaviti određene izazove upotrebljivosti jer će kod biti prikazan samo kratko vreme i može se promeniti dok ga korisnik čita, zahtevajući od korisnika da počne od početka.

Sledeća vrsta tokena je ona koja generiše autentifikacione kodove na zahtev (on-demand). Ovi uređaji koriste brojač koji se povećava svaki put kada je kod generisan i iskorišćen kao ulaz u algoritam koji se koristi u generisanju koda. Ovaj brojač je sinhronizovan sa autentifikacionim serverom, koji mu omogućava da potvrdi da je tačan kod prisutan. Autentifikacioni kodovi je jednovremenski password-i i ne mogu se ponovo iskoristiti jer će ih server odbiti. Ako krajnji korisnik preskoči da iskoristi kod, server će ga prihvatiti kao važeći dok god spada pod predetermisani prozor vazećih kodova. Server ovo radi računanjem svih važećih kodova počevši od trenutne vrednosti koju ima na brojaču sve do veličine prozora i onda ih upoređuje sa dobijenim kodom. Ako se kod slaže sa nekim od izračunatih kodova u prozoru, korisnik će biti autentifikovan i server će resinhronizovati brojač do vrednosti korišćene za taj kod a onda će ga povećati da bi odgovarao vrednosti kao na tokenu. Ovo dozvoljava korisnicima da se autentifikuju čak iako nemarno zatraže novi kod a da nisu iskoristili postojeći. Kao sa time-synced tokenima, ovo povećava rizik da napadač pogodi password zavisno od veličine prozora ali broj mogućih kodova je obično tako veliki da je takav rizik prilično mali. Jedna prednost ove vrste uređaja je da uopšte manje koštaju i traju duži period vremena od time-synced tokena jer ne proizvode kodove non-stop. Takođe ne doživljavaju nikakve probleme sa odstupanjem sata jer i ne koriste sat kao deo svog procesa. Jedna prepreka korišćenju ove vrste uređaja je da autentifikacioni kodovi mogu biti pregenerisani i zapisani, i dokle god da se koriste po redu biće važeći. Ovo će poništiti potrebu da token bude prisutan dok se vrši autentifikacija. To predstavlja ozbiljan rizik i može se savladati samo kroz obzirnost krajnjeg korisnika da bi se kodovi čuvali na sigurnom.

Treća vrsta token uređaja je kriptografska pametna kartica. Uopšteno ovo je implementirano kao kartica veličine i izgleda kao kreditna kartica koja poseduje malu dozu čuvane sigurnosti i procesor koji je sposoban za neke kriptografske funkcije. Kartica se ubacuje u čitač koji je aktivira i obezbeđuje interfejs prema sistemu. Smart-card tokeni su takođe implementirani koristeći uređaje koji upotrebljavaju USB konektore koji su dostupni na većini novijih kompijutera. Ovo je prednost nad implementacijom kartica jer odvojeni čitač ne mora biti povezan sa sistemom. Ovi uređaji obavljaju autentifikaciju tako što se oslanjaju na tip kriptografskog algoritma zvanog javni ili privatni ključ (public of private key). Ovi algoritmi koriste dva različita ključa, privatni ključ koji je sakriven i čuvan na uređaju, i javni ključ. Da bi se osiguralo da je tačan javni ključ povezan sa korisnikom, ključ i indentifikator korisnika su čuvani zajedno u obliku zvanom sertifikat (certificate). Sertifikat će se onda kriptografski overiti od strane poverljivog rukovodstva za sertifikate da bi se osiguralo da


V01.2009

Page 63

nisu izmenjeni. Ovaj sertifikat je onda čuvan u priručniku kao public key infrastructure (PKI). Algoritmi javnog ili privatnog ključa imaju svojstvo da podaci šifrovani korišćenjem privatnog ključa mogu biti dešifrovani samo samim privatnim ključem. Najšire korišćen algoritam javnog ili privatnog ključa je RSA algoritam, koji je dobio naziv po svojim stvaraocima – Rivest, Shamir i Adleman. Ovaj algoritam koristi uređaj da autentifikuje korisnika tako što šifruje challenge string koji je dobijen od sistema na kome korisnik pokušava da izvrši autentifikaciju. Ovaj podatak je onda dešifrovan sa javnim ključem korisnika od strane autentifikacionog servera koji proverava da li se šifrovanje izvelo uz pomoć privatnog ključa korisnika. Većina implementacija ovih uređaja će koristiti PIN da otključa karticu pre nego što obavi bilo koju funkciju. Korišćenje smart cards i public or private keys autentifikacije će takođe zahtevati da se koriste PKI i associated certificate authorities za rukovođenje i verifikaciju javnih i privatnih ključeva korišćenih za autentifikaciju.

Svi fizički tokeni poseduju odgovarajuće mere zaštite da bi se sprečio fizički napad. Kad bi token bio fizički kompromitovan i onda reverse-engineered ili ako bi odgovarajuće tajne informacije bile kopirane, onda bi mogao biti dupliran bez korisnikovog znanja. Ovo bi kompromitovalo token jer više ne bi bio jedinstven samo za osobu koja ga poseduje. Tokeni su obično u formi faktora koje je teško razbiti a da ga ne oštete do te tačke da neće funkcionisati i davati nikakve ključne tajne informacije da se pročitaju. Bilo je nekih napada na smart cards koji uključuju manipulaciju podataka koji su ubacivani u karticu da bi se šifrovali i onda merili vreme potrebno za to da bi otkrili informacije vezane za tajni privatni ključ. Ovi napadi su po prirodi potrošači vremena i zahtevaju specijalnu opremu da bi delovali. Takođe bilo je podešavanja na smart-card arhitekturi i processing-u da bi sukobljavali ove vrste napada. Ovi načini napada nastavljaju da budu oblast briga koje su u toku, jer upotreba token uređaja postaje sve rasprostranjenija.

Upravljanje tokenima Bez obzira na vrstu tokena koji se upotrebljava, mora postojati proces koji njime upravlja za vreme njegovog

životnog veka. Ovo uključuje početnu distribuciju tokena, zamenu izgubljenih ili istrošenih tokena i sakupljanje tokena od zaposlenih koji napuštaju kompaniju. Ovi procesi generalno koriste bazu podataka za upravljanje tokenima za vreme njihovog životnog ciklusa. Takođe je važno da procesi distribucije i zamene koriste odgovarajuće autentifikacione metode za verifikaciju da ispravna osoba dobija token. Ako se ovi procesi mogu oboriti onda sve sledeće autentifikacije mogu biti kompromitovane, jer neko drugi pored odgovarajuće osobe može biti u mogućnosti da dobavi token na svoje ime. Ovi procesi mogu koristiti poverljive činovnike obezbeđenja da verifikuju identitet ili se mogu vezati za metode korišćene za izdavanje credentials za fizički pristup preduzeću. Kao deo procedure za izdavanje tokena, alternativni metod autentifikacije se mora i treba ustanoviti. Jedan metod je da se postavi serija challenge-and-response pitanja koja se mogu koristiti preko telefona ili preko self-service Web site-a za zahteve akcija kao što su zamene ili resetovanja. Važno je da ova pitanja ne pitaju o lako dostupnim informacijama i budu raznovrsna da se ne bi pogađala lako. Generalno 3 do 5 pitanja izabrana iz gomile od 20 su dovoljna za ovu svrhu. Ova pitanja bi trebalo da se koriste samo u ovu svrhu i ne treba ih koristiti za day-to-day autentifikaciju. Ovo će smanjiti verovatnoću da će biti presretene.

Distribucija i upravljanje tokenima može dodati mnogo povišenja na totalnu cenu posedovanja tokena. Ovo je specijalno tačno ako tokeni moraju da se šalju individualno krajnjim korisnicima. Ako su vođeni centralizovanim procesom, trebaju da se plate ljudi koji će ih dodeljivati i bukvalno individualno pakovati za pošiljke. Metodi za slanje bi takođe trebalo dati razumno osiguranje da će token biti dostavljen samo osobi kojoj je namenjen. Ovo može povećati cenu procesa posebno ako je preduzeće na više geografijskih mesta. Ovi troškovi se mogu redukovati korišćenjem automatizacije koja će dodeliti tokene iz grupe nedodeljenih koji se nalaze na raznim mestima unutar preduzeća i ako je potrebno distribuira. Individue mogu iskoristiti Web portal da dodele sebi tokene, podrazumevajući da se mogu autentifikovati na zadovoljavajući način. U preduzećima koja zahtevaju više osiguranja da su tokeni dodeljeni odgovarajućim individuama, on-site security officers ili druge pouzdane individue mogu verifikovati identitet osobe pre nego što im dodele token.

Takođe postoji potencijal za kombinovanjem fizičke access kontrole značke zaposlenog sa onom od smart card-a koristeći istu formu faktora. Ovo se radi pisanjem informacije značke, obično imena, slike ili neke druge enterprise informacije, na samu smatr-card. Ovo daje preduzeću opciju korišćenja smart-card informacije o autentifikaciji za kontrolu stvaranja pristupa. Ovo takođe olakšava ukidanje pristupa; kada zaposleni napusti organizaciju i značka ili smart-card se vrate, neće im samo zabraniti ulaženje u zgradu već i pristup bilo kom elektronskom sistemu ili aplikaciji koji koriste smart-card.

Zaključak Autentifikacione šeme koje koriste statične password-e kompromituju se sve više od strane napadača koji koriste

nadgledanje mreža, virusa koji na radnim mestima instaliraju keylogges, pogađivanja password-a i phishing-a koji vara krajnjeg korisnika da prosledi akreditivna pisma trećem licu. Ovi napadi postaju sve češći. Druge metode autentifikacije moraju biti implementirane da bi se smanjila sposobnost napadača da kompromituju one sisteme i aplikacije koje koriste statične password-e. Biometričke šeme koje implementiraju autentifikacioni faktor ’’nešto što jesi’’ bi takođe bile efektivne ali rešenja su i dalje nekako nezrela i ostaju teška za implementaciju posebno sa legacy systems. Token autentifikacione šeme koje implementiraju dva od tri faktora autentifikacuje, ’’nešto što znaš’’ (PIN) i ’’nešto što imaš’’ (token uređaj), izgledaju


V01.2009

Page 64

kao najbolje rešenje da bi se sprečile ove vrste napada. Autentifikacija tokenom bi bila lakša za preduzeće da implementira i mnogo bi smanjila rizik da autentifikaciona šema bude kompromitovana unutar preduzeća.

4.2. Administracija kontrole pristupa, domenska struktura 4.2.1 Uvod Šta je odgovornost i zašto niko nije voljan da implementira pouzdane mere odgovornosti? Odgovornost nit je

popularna na poslu nit je dovoljno atraktivna da bi je tehnologičari implementirali i na kraju, profesionalci sigurnosti mogu jedva držati korak sa revizijama. Prvo ste ovde čuli: odgovornost će biti sledeća verzija revizije, upravljanja indentitetima i administracije sistema.

Odgovornost je nešto što dobivate suprotno od ’’namesti i zaboravi’’. Svi traže srebrni metak da ubiju spektar predusetljivosti i propisa. Ali ne postoji takav srebrni metak. Jačina naše revizije svete vode postaje opasno razblažena od strane stava ’’uključi to kad revizor dođe’’. Vreme je za odgovornost tehničkog i poslovnog procesa.

Pretpostavke Da bi imali jasnu diskusiju o odgovornosti, ovo poglavlje će biti ograničeno domenom kontrole pristupa. U domenu

kontrole pristupa, jedinstvena indentifikacija se podrazumeva; bez nje, ni jedan od ovih koncepta ili metodologije kontrole pristupa ne bi bio uspešan.

Discretionary access control (DAS) neuspesi sistema su razlog potrebe za odgovornošću; zato je DAC druga predpostavka ovog poglavlja. Moguće je podesiti koncepte odgovornosti da se prilagode role-based i mandatory sistemima kontrole pristupa.

Držite na umu, autor dolazi iz Windows background-a. Drugi deo ovog poglavlja diskutuje o Windows file sistemima i alatima za adress logging ’’Windows style’’. Tehnologije o kojima se diskutuje u ovom poglavlju se mogu izdvojiti da bi se prilagodilo drugim situacijama kao što su implementacija i sistemi relacionih baza podataka (UNIX-like).

Domen uprave sigurnosti informacija preklapa se preko ove teme specijalno u oblasti polise. Polise na saglasnost za nadgledanje, procedure eskalacije i revizije se podrazumevaju za uspeh odgovornosti na bilo kom nivou. Fizičko obezbeđenje se podrazumeva da je jako.

Osnovne predpostavke o jedinstvenoj identifikaciji, DAC i Windows-u će pomoći da se suzi opseg ove teme u poglavlje umesto u čitavu knjigu.

Definicija i potreba Formalna definicija odgovornosti je sledeća: princip je da su individue, organizacije i zajednice odgovorni za svoje

akcije i može se zatražiti od njih da drugima objasne te akcije. Po CISSP zahtevima, organizacija će očekivati od svojih pripadnika da se povinuju polisi ili pravilima i, ako postoji neuspeh u saglasnosti, rukovodeće telo će imati znanja o prekšaju(ima) i preduzeti akcije. Svaka od ovih komponenti zahteva posmatranje za CISSP da ih primeni svom poslu.

Ko rukovodi akcijama? Koje su predostrožnosti? Individua je pripadnik mnogih grupa ili skupova. Na primer: ti si član porodice, zajednice, organizacije i biznisa. Ako uradiš nešto pogrešno na proslavi porodičnog slavlja (da, svi su videli šta si uradio), jedan ili više članova porodice će te pozvati sutradan i nagrditi te. Ako uradiš nešto pogrešno kao CISSP (ne opet?), (ISC) Ethics Review Board će ti poslati neprijatan e-mail i možda povući tvoju članarinu. Ako uradiš nešto neprihvatljivo na fajl serveru na poslu, automatski ćeš dobiti poruku koja objašnjava narušavanje polise i advokat tvoje organizacije će očekivati da zakažeš sastanak da razjasnite situaciju. Ovaj savršen svet posledica za neprikladne akcije se može ostvariti preko miksa tehničke i administrativne kontrole fokusirane na odgovornosti.

U savršenom svetu, svako bi shvatao namere pravila i poštovao ih. Sa pristupom da su ljudi u suštini dobri, trening bi bio odgovor za postavljanje jasnih očekivanja i prevenciju neprikladnog tumačenja pravila. Bilo kako bilo, u nesavršenom svetu, ljudi su u konstantnom stanju promena. U najviše slučajeva, način na koji je informacija prezentovana će imati jačinu koliko je dobro primnjena i poštovana. Na primer, chief executive officer (CEO) kluba zdravlja kaže, ’’Ustanovljavamo nov sistem odgovornosti. Testiranje na drogu će se raditi svakog dana. Znaćemo šta ste jeli, pili i radili sinoć. Ako uradite nešto pogrešno, otpušteni ste!’’, kako će se osoblje osećati u tom trenutku?

Daj da počnemo odpočetka. CEO veruje da žele da unaprede zdravlje osoblja tako što će im pokazati kako da poboljšaju dijetu, vežbanje i vitaminski balans. Kakav bi bio osećaj sada? Ista implementacija odgovornosti se moze različito tumačiti. Uspešne implementacije strategija odgovornosti zahtevaju uglađena ispunjenja očekivanja i preciznu tehnologiju.

Nažalost, organizacije krše propise, ljudi krše pravila i polise; one koje uhvate budu kažnjeni. Dakle kada se ovo događa? Revizori zakazuju sastanke sa organizacijama da pregledaju njihove aktivnosti ili zbog žalbe ili kao deo periodične inspekcije. Retkost je da iznenadna ili nasumična inspekcija se desi bez nekog upozorenja. Pre nego što revizor stigne, svi se


V01.2009

Page 65

rastrče unaokolo uključujući kontrole. Revizor proverava polisu protiv kontrola, tražeći pukotine. Revizori će kopati dok nešto ne nađu a onda podneti izveštaj rukovodećem telu. Rukovodeće telo deli kazne ili, u najviše slučajeva, upozorenja. Pošto revizor ode, kontrole se isključuju, život teče dalje.

Šta bi trebalo da se dogodi? Kad su se kontrole isključile, rukovodeće telo i odgovorna osoba u organizaciji su automatski trebali da budu obavešteni, pozivi su trebali da stignu poštom i kontrole bi se onda ponovo uključile ili bi se platila kazna. Sledeći put kad se budeš vozio putem i video kako policijski auto nekoga zaustavlja, da li ćeš usporiti? Sledeći put kad te uhvati kamera na crvenom svetlu, da li ćeš platiti kaznu ili otići na sud? Sledeći put kad vidiš kameru da li ćeš stati? Kako bi bilo poštovati zakon sve vreme?

To je ono za šta odgovornost stoji; to je poslovni i tehnički proces koji menja svačije ponašanje da bi poštovali propise sve vreme.

Na primer, zamisli da uradiš nešto neprihvatljivo. Dobio bi e-mail od sistema a kopija bi otišla tvome šefu. Zahtevalo bi se od tebe da se pojaviš za njenim ili njegovim stolom spreman da objašnjavaš. Kao odgovoran član organizacije i zrela odrasla osoba, nećeš praviti izgovore; izvinićeš se i nećeš to ponoviti. To neće biti zabavan deo dana. Ako zaposleni znaju da neprikladne akcije imaju posledice, brzo nauče da ne rade takve stvari.

Potreban nam je odgovorni sistem koji se obraća svetu u kome živimo. Potreban nam je poslovni proces i tehnički set alata koji prijavljuje sve neprilične aktivnosti tako da bi samo-korektivne mere bile primenjene.

Pregled zahteva Odgovornost zahteva balans između implementacije i procesa poslovanja. Oslanjajući se previše na bilo koji od njih

smanjiće se odgovornost. Ako imamo loše automatizovan način da dostavimo podatke, proces poslovanja ne može jednako primeniti pravila i sanaciju. Kad imamo nepravilno primenjivanje polise, dovešće do preinačenja odluka ili od ljudskih resorsa ili, još gore, od strane zakona. Svi smo čuli priče o sudskim odredbama organizacijama da vrate zaposlene koji su otpušteni.

Administrativno mora postojati jasna, tačna polisa i pravni lek za nesaradnju. Tehnički mora postojati jasna definicija, sistemi tačnih dozvola, konsolidovano logovanje i vremenska e-mail komunikacija između svih učesnika.

Detalji poslovnog procesa Pre nego što se pozabavimo tehničkim procesima moramo prvo staviti na mesto poslovne procese. Moramo prvo

definisati akcije, a onda možemo definisati i one neprimerne. Moramo izabrati rukovodeće telo iz ljudstva za eskalaciju i sanaciju. Moramo definisati mere predostrožnosti. Dobro definisan posao ima svoje funkcije i tokove dokumentovane. Ovi podaci su trenutno u većini organizacija. Mogu biti u riziku dokumenti uprave, udarna procena poslovanja ili okvir uprave.

Podaci koji su nam potrebni za definisanje akcija uključuju opise, uloge i odgovornosti svih radnih mesta u organizaciji. Ovo se ne može odraditi u vakuumu jednog odeljenja. Ako ispitamo uloge i pojavi se višak, moramo doznati zašto i napraviti podešavanja, ako je moguće. Svaka pozicija ili uloga će imati definisan set resorsa kojima ne priliči da pristupaju drugi. Dalje, u zreloj definiciji pristup resursima bi bio što je zrnasto moguć. Naš cilj je da odgovorimo na pitanja, koje su najmanje privilegije, šta su to grupe, a šta su resorsi? U većim organizacijama ovi podaci mogu biti u fajl sistemima, direktorijumima ili sistemima uprave indentiteta.

Ako su podaci prisutni, najverovatnije trebaju konsolidaciju. Maksimalan broj grupa bi trebalo da bude manji od 25 za organizaciju ili veliko, segregated odeljenje. Maksimalan broj resorsa bi trebalo da bude 25. Razlog za ove brojeve je da moguć broj permutacija grupa i resorsa može biti toliko veliki da administratori ne mogu napraviti njihov dijagram illi koncepciju. Moguće je prekoračiti ove maksimume, ali u najvećem broju slučajeva upotrebljava se konsolidacija. Teškoća sa ovim korakom je sledeća: dodatne administrativne promene preko života posla, pozicije i seta resorsa. Izlaz iz ovog koraka će se iskoristiti za definiciju funkcionalnosti polisa.

Pristanak na nadgledanje, prihvatljiva upotreba resorsa, sanacija, samo-upravljanja i eskalacija su funkcionalne polise koje se moraju definisati za korišćenje u tehničkoj implementaciji odgovornosti. Kao i uvek, polisa se mora saopštiti osoblju pre, za vreme i posle zaposlenja. Pristanak na nadgledanje mora definisati nivo praćenja aktivnosti i dati čiste primere. Prihvatljivo korišćenje resorsa mora uključivati izjavu koja specijalno pokazuje na ne korišćenje imenovanih fajlova i baza podataka koji nisu deo spektra uloge te grupe; dalje, osoblje mora biti upozoreno na čuvanje korisničkog računa koji je imovina organizacije. Prihvatljiva upotreba se mora odnositi na ostale tri navedene polise. Polisa sanacije mora objasniti sledeće: koraci koje bi trebalo napraviti u slučaju da je narušena prihvatljiva upotreba polise, ko će biti kontaktiran ako se pojavi prekršaj, izuzeci, tipične kazne i broj prekršaja pre nego što se desila eskalacija. Polisa samo-upravljanja (takođe zvana priručnik etike), ako prisutna, bi trebalo da objasni prihvatljivo i neprihvatljivo ponašanje jer se odnosi na odgovornost. Polisa eskalacije mora imenovati ili se obratiti strankama kao što su union representation, legal counsel, employee review boards i human resources.


V01.2009

Page 66

Employee review boards su grupa istih po statusu koji saslušavaju izuzetke i prave preporuke prestupniku. Ova grupa bi trebalo biti mix svih odeljnja, sa varitetima stalnih mesta i treba se često menjati. Može imati većeg uticaja od uprave. Zaviseći od kulture organizacije, review boards mogu davati predloge za terminaciju ili kaznu. Sama pomisao na razočaravanje ’istih po statusu’ u nekim organizacijama će biti zastrašujuća za dalje neprikladne akcije.

Detalji tehničkog procesa Svi poslovi mogu implementirati odgovornost; ali tehničko odeljenje mora biti u redu. Minimalni zahtevi su

jedinstven identitet; pravilno imenovani resursi i grupe; precizne dozvole; precizno, konstantno, jezgrovito logovanje; automatsko izveštavanje ili relevantano logovanje i dobro odrzavanje svega gore navedenog.

Strategija uprave identiteta sadrži konsolidaciju ili sinhronizaciju autentifikacije baza podataka, grupisanje funkcionalnog ili odeljenskog osoblja i grupisanje resorsa. Organizovanija grupa strategije upravljanja od povezanih grupa vlasnika do njihovih imenovanih resorsa koristi jasnu konvenciju imenovanja koja će povećati jasnoću odgovornosti. Ako je resors jasno markiran ili imenovan i organizovan za korisničko odeljenje ili funkciju, korisnici će imati veću verovatnoću da pristupe tačnim resorsima. Obratno, korisnicima će biti jasno da neprimerna akcija nije deo njihovog domena sigurnosti. Primer u implementacionoj sekciji ovog poglavlja će ovo pojasniti.

U većini enterprise sistema dozvola, administratori su ili zbunjeni zbog efektivnih dozvola ili koriste strategiju ’’najveće privilegije’’, rađe od strategije najmanje privilegije. Korisnici resorsa bi trebalo da budu u što manjem konfliktu dozvola grupa što je moguće. Dozvole bi trebalo da budu primenjene što bliže resorsu što je moguće i grupisanje bi trebalo da bude rasejano po lokalnom resorsu.

’’Antigrupa’’ se sastoji od grupe svog osoblja koje ne bi trebalo da ima pristup određenom resorsu, to jest, grupa bez dozvole. Antigrupa je termin koji je autor stvorio zato što je koncept merodavan uspehu odgovornosti. Antigrupi bi specijalno trebalo zabraniti pristup resorsima tehničkim sredstvima. Ako se ovo desi i uprava celokupne grupe je tačna i automatizovana, biće lakše implementirati odgovornost.

Precizno logovanje je poslednji ključni deo zagonetke koju odgovornost predstavlja. Tradicionalno, nivoi logovanja su bili ili previše veliki ili previše mali. Hvatanje u klopku svih događaja uzrokuje loše performanse, probleme skladišta i log konsolidovane greške. Hvatanjem u klopku previše malo log ulaza maši se ključni događaj. Logging svih vrsta pristupa (uspešnih i ne) od strane antigrupe saopštava sve što je potrebno za odgovornost. Uspešan pristup od strane antigrupe ukazuje na greške podešavanja dozvola i zahteva trenutnu akciju od strane administratora. Neuspeli pristup od strane antigrupe ukazuje na pitanja odgovornosti koje treba prijaviti kao što je naloženo u polisi. Ako je grupna konsolidacija utegnuta sa strategijama antigrupe, logovanje je skoro savršeno.

Indirektno vezan za odgovornost je postupak podešavanja samog sistema za logovanje. Promene postrojenja za logovanje ukazuju na promene polise. Tehnička ili administrativna promena polise bi trebalo biti pažljivo pregledana pre implementacije; od toga zavisi garancija odgovornosti.

Automatsko prijavljivanje kršenja odgovornosti je zadnji korak u setu tehničkih procesa. Da bi se limitirao ugovor, smanjila tenzija između zaposlenih i pružila trenutna povratna mera prekršiteljima, sve prijave i eskalacije ne smeju imati ljudsku intervenciju do pošto optuženi dobije šansu da razmotri svoje akcije.

Usaglašavanje tehničkih i poslovnih procesa koji okružuju odgovornost su od posebnog značaja za posao. Pošto su prekršaji registrovani, metapodaci će ukazivati na rupe između onog što je razumno da bi se ostvario poslovni cilj i onog što je zapisano u polisi. Strategije odgovornosti će imati najmanje tri ponavljanja da bi postale stabilne i pouzdane.

Implementacija tehničkih procesa Drugi deo ovog poglavlja je opis implementacije odgovornosti. Iskoristićemo norme tehničkih implementacija za

organizacije od operativnog sistema koji je najviše zastupljen i tipičnu strukturu za građenje implementacije odgovornosti. Microsoft’s Active Directory za verziju 2000 ili bolju sa omogućenim Global Groups ima najširi auditorijum. Uz neke modifikacije, ovaj sistem bi mogao da radi za neke druge sisteme ili atipične dizajne.

Predpostavke za ovu implementaciju odgovornosti su sledeće: struktura pod Windows domenom jedne šume (forest), univerzalne grupe, dozvole koje se odnose samo na grupe, univerzalna konvencija imenovanja za obe grupe i deljene resorse, dozvole stavljene na svaki dostupan resors, logging događaj za sigurnosne i sistemske događaje i Logcaster (alat za log konsolidovanje).

Velike strukture Windows domena kojima je prvenstven Windows 2000 su tipično postavljeni kao resursni domeni verujući domenima računa da prevaziđu limitacije u veličini baza podataka. Ovo više nije potrebno, ali koncept i dijagram će pomoći da se ilustruje domen koji je dovoljno kompleksan da se može primeniti na većini preduzeća (Slika 4.6 Primer strukture domena ). U ovom domenu strukture, korisnički račun je zaključan u a.com domenu, a fajl server je zaključan u odvojenom domenu, r.com. Oba domena su zaključana u jednom forest da bi se mogao dogoditi odgovor baze podataka.


V01.2009

Page 67

Univerzalne grupe su osnovane samo u forest-u gde je funkcionalni nivo podignut na Windows 2000 prirodni režim za sve domene u forest-u. Ovo se ne može poništiti osim ako ne povratiš sve kontrolore domena iz backup-a. (jako upozorenje: ako podignete funkcionalni nivo i imate bilo koji NT 4.0 domen, izgubićete sposobnost replikacije) Podizanje funkcionalnog nivoa se može ostvariti u Microsoft Management Console (MMC) za Active Directory Domains and Trust pritiskom na desni klik na svaki od objekata domena i biranjem iz dopunskog menija.

Iz Help file-a Windows 2003 servera: Koncept omogućavanjanja dodatne funkcionalnosti u Active Directory-u postoji u Windows-u 2000 sa miksovanim i prirodnim modovima. Modovi miksovanih domena mogu sadržati Windows NT 4.0 backup kontrolore domena i ne mogu da koriste Universal security groups, group nesting, and security ID (SID) history sposobnosti. Kada je domen postavljen na prirodni mod, Universal security groups, group nesting, and security ID (SID) history sposobnosti su omogućene. Kontrolori domena koji rade pod Windows 2000 serverom nisu svesni domain and forest funkcionalnosti.

Slika 4.6 Primer strukture domena

Moguće je ostvariti odgovornost na odvojenim forest-ima koristeći centralizovanu logging ustanovu, ali nivo kompleksnosti se povećava.

Dozvole moraju biti postavljene na resorse na nivou grupe na ugnežden način da bi se redukovali konflikti i zbunjenost dozvola. Nezvanično biranje stotina administratora sistema preko sedam godina ukazuje na tri stvari: postoji ogromno stanište konfuzije na temu kako pravilno da se postave dozvole, kakav efekat imaju nagomilane dozvole na deljenje, i kako počistiti permissions creep koji se javlja tokom životnog veka account-a.

Administratori dozvola bi trebalo da koriste praktičan pristup sistemu dozvola. Praktičan pristup sa Discretionary Access Control Knowledge, a Practical system nudi novo rešenje za administratore da redukuju zloupotrebu kontrole pristupa i uproste upravljanje dozvolama.

Ako koncepte od ’’THE SNAIL’’ i najbolje delovanje poštuju, administratori će moći da redukuju konfuziju računanja efekata zbirnih dozvola. Korišćenje THE GRID i THE FIVE RULES omogućavaju administratorima da brzo indentifikuju i redukuju ranljivosti...’’ 1

Ovaj dokument takođe daje detalje konvencija imenovanja za grupe. Kada su neprilične akcije logged, mora postojati jasno razumevanje ko je šta uradio i kad. Implementacijom standardnog imenovanja za grupe, znamo ’’ko’’. Implementacijom standardnog imenovanja za resorse, znaćemo ’’šta’’. Ako imamo vremensku sinhronizaciju sa eksternim vremenskim serverima, znamo ’’kada’’.

Organizacije grupa bi trebalo da prate ’’the snail’’ koncept stavljanja samo korisnika u globalne grupe, stavljanje globalnih grupa u univerzalne grupe i stavljanje univerzalnih grupa u domene lokalnih grupa (Slika 4.7 Gnezdeće grupe).

1 - http://www.sans.org/reading_room/whitepapers/windows/1165.php.


V01.2009

Page 68

Ovakva organizacija grupa dozvoljava sporu migraciju ka zrelom položaju odgovornosti. Konvencije za imenovanje bi trebalo da podrže jasan put od korisničkog računa do resorsa i njihovih dozvola. Sledi primer konvencije za imenovanje:

Domain local groups

LgDepartmentFoldernamePermission

If there is a deny permission, precede it with ’’x’’

Universal groups

UgDepartmentFoldernamePermission

If there is a deny permission, precede it with ’’x’’

Global groups

GgDepartment

Koncept antigrupe kritičan za implementacije odgovornosti da rade je upotrebljen za dodeljivanje xUg grupi sve globalne grupe koje nemaju dozvolu za resorse. Ovo može imati visoku administrativnu cenu ako taj dokument nije iskorišćen.

Slika 4.7 Gnezdeće grupe

Ova konvencija za imenovanje će učiniti dostupnom brzu indentifikaciju administrativne greške i sposobnosti da pronalazi probleme odgovornosti. Imenovanje i organizacija grupa će podržati odgovornost ako su vlasnici dodeljeni u Active Directory pod ’’Managed by’’ petljom grupe.

Konvencije za imenovanje i grupne odgovornosti će pomoći sa deljenjem dužnosti. Server operatori koji su odgovorni za file and print servere mogu limitirati svoje aktivnosti da kreiraju podele, postavljaju dozvole za domen lokalnih grupa i postavljaju revizije za iste grupe. Administratori domena za domene resorsa mogu limitirati svoje aktivnosti za kreiranje domena lokalnih grupa i dodeljivanje domena lokalnih grupa domenima univerzalnih grupa. Administratori domena za domene računa mogu limitirati svoje aktivnosti za kreiranje i dodeljivanje korisnika globalnim grupama i kreiranje i dodeljivanje globalnih grupa univerzalnim grupama. Moguće je u veoma zreloj strukturi odgovornosti da se identifikuje neprilična kreacija grupe.

Dozvole se mogu postaviti na tri nivoa unutar Windows operativnog sistema: share, NTFS (NT File System) folder i NTFS file. Da bi se redukovala konfuzija postave se deljene dozvole na punu kontrolu od strane svih. Mnogi administratori se na ovaj predlog uznemire. Deljive dozvole, ako se ostave same, nikad nisu dobra strategija kontrole pristupa. Moraju biti


V01.2009

Page 69

podržane od stane NTFS folder dozvola da bi održale najmanje privilegije. Ne bi trebalo da bude potreba za NTFS file dozvolama. Administrativno, ovo bi trebalo da su jedine dozvole; ovo se može ostvariti samo menjanjem naprednih podešavanja da bi se uklonilo nasledstvo dozvola. Ovo se ostvaruje uklanjanjem čekiranja na ’’Allow inheritable permissions from parent’’ checkbox-u.

U ovom trenutku administratorska grupa i dalje održava punu kontrolu. Ova grupa sadrži lokalni administratorski račun registra i po default-u sadrži domen administratora lokalnog domena kao jednog od njegovih članova. Ako administratori ne mogu da podese dozvole, ne mogu da rade svoj posao. Ova dozvola bi trebala da se ostavi na miru da bi videli kada administrator pravi izmene.

Kada pravimo ili podešavamo grupnu članarinu, organizacija bi možda želela da stavi sve grupe u jedan aktivan directory container da bi sprečila polisu domena nasledstva od promene konfiguracionih prava. Ova strategija takođe povećava brzinu pretraživanja direktorijuma.

Izvršavanjem pomenutih administrativnih zadataka, korisnici su u tačnim grupama, gneždenje tipova grupa za organizaciju je ostvareno, efektivne dozvole se mogu postaviti, antigrupe su na mestu i moguće je ostvariti odgovornost preko event logging-a. Rezultat bi trebalo da izgleda kao Slika 4.8 Kompletan dijagram implementacije odgovornosti. Trebalo bi da budu dve do četiri dozvole postavljene na resors: lokalni administrator sa punom kontrolom, antigrupa sa zabranjenom punom kontrolom i jedno ili dva odeljenja sa njihovim postavljenim najmanjim privilegijama.

Event logging je core tracking mechanism za odgovornost. Trebalo bi ga konfigurisati na nivou domena polise a ne na nivou lokalne polise. Za filtere, reviziju bi trebalo postaviti na uspeh i neuspeh za pristup objektu i uspeh i neuspeh za promenu polise. Ako je dodatna revizija uključena, dodatni događaji koji nemaju veze sa odgovornošću će biti zapamćeni.

Slika 4.8 Kompletan dijagram implementacije odgovornosti

Jednom kad se revizija uključi na serveru i konfiguriše na domen nivou, objekti ili resorsi se mogu uspešno naći. Revizioni tab na advanced security settings za resors trebalo bi izvršiti reviziju za dve grupe kojima ne treba pristup na regularnoj bazi: administratori i antigrupa. Drži na umu, antigrupa je svako ko nema dozvolu. Antigrupa je definisana od strane administratora domena računa na nivou univerzalne grupe dodavanjem globalnih grupa kojima nije potreban pristup resursima odeljenja. Ako administrator dozvola ne uspe da postavi odbijanje svih dozvola a postavio je reviziju za oba, uspeh i neuspeh, neprikladan pristup će i dalje biti logovan. Ovo je moguće samo za antigrupu, a ne napravljenu ’’svačiju grupu’’. ’’Svačija grupa’’ sadrži sve koji imaju pristup mreži, što uključuje ljude sa dozvolama. Ako su svi revizovani i neprikladan pristup i tačan pristup će se logovati. Cilj je da se loguje samo neprikladan pristup. Administrator mora videti i uspešan i neuspešan događaj revizije pri pristupanju resorsima od strane antigrupe. Uspešni revizioni događaji ukazuju na netačno


V01.2009

Page 70

postavljene dozvole. Neuspešni revizioni događaji ukazuju na neprikladne pokušaje. Koristeći antigrupu kao grupu za logging events, prvi deo odgovornosti je ostvaren.

Aktivnosti i od prekršaja krajnjeg korisnika i od administrativnog održavanja moraju biti sakupljene, napakovane i iskorišćene. Korišćenje podataka za našu inicijalnu svrhu je odgovornost. Polisa se mora podesiti da bi odgovarala realnim radnim uslovima, zato što će podaci odgovornosti ukazivati na rupe. Zato što su samo neprikladne aktivnosti sakupljane, kolekcije i zalihe podataka logovanja će biti redukovani na pogodniji nivo za pregled. Korišćenje alata za skupljanje događaja logovanja kao što je Rippletech-ov Logcaster će nam pomoći da zarobimo kritične događaje kako se dese, umesto u trenutku offline skladištenja. Kritični događaji kao što su prestupi odgovornosti, promene polisa, promene revizija i promene dozvola bi se trebale povinovati trenutnom pregledu od strane menadžera odeljenja, komisije za odgovornost ili krajnjeg korisnika. Trenutni pregled vezuje akcije za konsekvence. Automatizovan izlaz dozvoljava trenutan pregled bez odluka od strane timova za sigurnost ili administratora. Kritični događaji se mogu desiti preko e-mail-a.

Treba biti oprezan pri prvoj implementaciji e-mail obaveštenja zbog potencijalnog odbijanja usluge. Sažimanje je najbolja strategija za automaciju pre nego što su false-positives redukovane na upravljiv nivo. Bilo koji nekritični događaj kao što je pristup administratora bi trebalo biti sakupljen, sumarizovan i pregledan u razumnom vremenskom periodu.

4.2.2 Pretnje Odgovornost ima mnoge administrativne pretnje. One sadrže preduslovne neuspehe, neuspehe implementacije,

neuspehe održavanja i pogrešno obeležavanje. Preduslove za jedinstvenu indetifikaciju i upravljanje identitetima je teško postići i održavati. Držeći ljude odgovornim, administratori moraju biti sigurni da jedan račun koristi jedna i samo jedna osoba. Bila bi loša forma da se kazni neko zbog tuđih akcija. Deljeni računi administratora biće najproblematičniji ako je namera da se primeni odgovornost funkcijama tehničke administracije.

Inicijalni neuspesi implementacije mogu sadržati veliki broj false-positives-a ako sistemi odgovornosti nisu instalirani po fazama.

Da bi adresirali neuspehe održavanja, imajte na umu da se dozvole menjaju. Privlačno je da se ostavi prošli set dozvola na mesto i dodaju nove dozvole. Prema ovom prestupu najmanje privilegije bi se trebalo ophoditi izvođenjem redovnih pregleda. Dodatni neuspesi održavanja mogu biti prouzrokovani promenom osoblja na administrativnoj strani, nekontrolisanim rastom osoblja i nedostatkom automatizacije.

Organizacije mogu lako pogrešno obeležiti odgovornost kao reviziju. Ali revizija je periodično ocenjivanje rupa između polisa i implementacija od strane trećeg lica. Odgovornost je trenutno obaveštenje o rupi i korekcija od strane upletenih lica.

Postoje nekoliko tehničkih pretnji, uključujući cenu logovanja, manjak vaspitanja i potreba za centralizacijom. Čin logovanja ima vrednost dolara. Neke organizacije već imaju logovanje na mestu; one koje nemaju će počinjati od početka i, zbog toga, trošiti više. Manjak vaspitanja na dozvolama i konsolidaciji logovanja stvara veliki deo nepotrebnog prekoračenja na sistemima odgovornosti. Centralizacija logovanja, autentifikacija i polisa su potrebni za većinu organizacija da ostvare odgovornost.

4.2.3 Ko treba biti angažovan u sprovođenju politika odgovornosti? Lak odgovor je da svako treba biti angažovan. Tvorci polise, tehnologičari, zaposleni i revizori, znači svi treba da

budu deo programa odgovornosti. Pojačanje u obliku tvorca polise mora biti definisano i implementirano od strane tehnologičara na hands-off način. Tvorci polise bi trebalo da stvore pravila i definišu posledice tako da zaposleni preuzmu na sebe samo-korekciju. Ako se pravila ne budu poštovala u razumnom vremenskom periodu, ljudski resorsi ili odbor zaposlenih bi trebalo da istupe. Revizori bi trebalo da uzmu podatke iz sistema odgovornosti i podese polisu ili radne navike. Ako se svi angažuju, odgovornost će promeniti kulturu organizacije na bolje.

zaključna razmatranja Sigurnost nije ’’namesti i zaboravi’’; odgovornost najviše čuva ovo u našim glavama. Odgovornost ostvaruje svest

verifikovanjem svake akcije definisane u polisi. Kad su svi svesni, naši rizici za naše resorse se smanjuju. Samopouzdanje je povećano naredbom od važnosti kada se sigurnost pomera sa obaveze od nekoliko na onu od čitave organizacije.

Ne pokušavajte da idete za svakom neprikladnom akcijom odjednom. Počnite od jednostavne, easy-to-be-right akcije. Na primer, samo odeljenje za računovodstvo bi trebalo da bude na platnom spisku. Radite dalje dok ne dođete do težih odluka. Odgovornost je moguća.


V01.2009

Page 71

4.3. Odbrana od zlonamernih programa, antivirusna politika 4.3.1 Definicija zlonamernih programa Od svih stvari koje se pojavljuju u polju informacionih sigurnosti, nekoliko su više interesantne (takođe i vise

problematične) od incidenta sa zlonamernim kodom (“malware”). Tokom godina videli smo evoluciju malware-a od prostog virusa napisanog u assembly jeziku do kompleksnih programa koji donose naprednu funkcionalnost koja u mnogome olakšava sposobnost počinitelja da ostvari svoju koristoljubivu svrhu. U ovom poglavlju rootkit-e smo nazvali “ultimativnom malware pretnjom”, nešto što u svakom slučaju nije izmišljotina. Kada je reč o sofistikaciji i potencijalu za štetu, gubitak i uništenje, nekoliko, ako uopšte, tipova malware-a mogu da se porede sa rootkit-ima. Sa konstantnim informacijama o virusima, crvima i Trojan horse programima, rootkits su se nekako “izgubili u magli”. Ovo poglavlje je namenjeno da služi kao poziv na buđenje – vreme je za profesionalce informacionih bezbednosti da postanu svesni o tome šta su to zapravo rootkits, šta oni mogu da urade, kakve rizike predstavljaju i moguća rešenja za kontra-napade na njih.

Profesionalci informacionih bezbednosti su konstantno zabrinuti o širokom varitetu pretnji vezanih za bezbednost. Neke od tih pretnji predstavljaju značajno velike nivoe rizika od ostalih i zato zahtevaju više resorsa za protiv-napad na njih. Čak šta više, rizici i njihov potencijalni udar menjaju se tokom vremena. 1990-ih, na primer, neki od najozbiljnijih rizika su oni koji su bili rezultat aktivnosti eksternih napadača. Napadači najčešće koriste brute-force password-guessing napade ili, ako su više sofisticirani, password-cracking napade koristeci password-cracking alate bazirane na rečniku koji su po današnjim standardima prilično nezreli. Za to vreme, šteta i poremećaji od strane virusne i crvne infekcije takođe su sadržani u jedan od najozbiljnijih tipova rizika za sigurnost. Stvari su se znacajno promenile od tada; određeni tipovi malware-a pored virusa i crva su se pomerili na prva mesta sto se tiče rizika sa kojima se organizacije trenutno suočavaju. Rootkits narocito sada predstavljaju ono sto se može slobodno nazvati ultimativna malware pretnja. Ovo poglavlje pokriva “unutrašnjost i spoljašnost” rootkits-a, veze između rootkits-a i rizika vezanih za sigurnost, kako sprečiti rootkits na prvom mestu da budu instalirani, kako ih primetiti i oporaviti se posto su rootkits instalirani na žrtvinom sistemu.

4.3.2 O Rootkits-ima Šta je tačno rootkit? Odeljak koji sledi definiše šta su to rootkits, opisuje njihove karakteristike, objašnjava kako se

rootkits i Trojan horse programi razlikuju i opisuje kako rootkits rade.

Definicija rootkit-a Termin “rootkit” odnosi se na tip Trojan horse programa koji ako je instaliran na žrtvin sistem menja software

operativnog sistema tako što: (1) dokaz o aktivnostima napadača (uključujući i bilo kakve promene na sistemu načinjene prilikom instalacije rootkit-a) je sakriven i (2) napadači mogu dobiti daljinski backdoor pristup sistemu po volji. Rootkits vrše zamenu normalnih programa i sistemskih biblioteka koje su deo operativnog sistema na žrtvinoj mašini sa verzijama koje se površinski gledano čine normalnim, ali u stvarnosti obaraju sigurnost mašine i uzrokuju izvršenje zlonamernih funkcija.

Karakteristike rootkit-a Rootkits skoro bez izuzetaka rade sa superuser privilegijama, punim pakovanjem odnosno nizom sistemskih

privilegija koje su namenjene samo za administratore i programere sistema, tako da oni mogu lako da izvrše bukvalno svaki zadatak po volji. U UNIX i Linux OS, prenose se na root-level privilegije; u Windows OS, one predstavljaju Administrator- i SYSTEM-level privilegije. Bez superuser privilegija, rootkits ne bi bili veoma efektivni u ostvarenju zlonamernih funkcija koje podržavaju. Vazno je shvatiti da napadači moraju dobiti superuser-level pristup pre instalacije i pokretanja rootkits-a. Rootkits nisu alati iskorišćeni za podizanje nivoa privilegija onih koji ih instaliraju. Napadači moraju zato istražiti jednu ili više ranljivosti nezavisno od funkcionalnosti bilo kog rootkit-a da bi dobili superuser privilegije na žrtvinom sistemu da bi mogli da instaliraju i pokrenu rootkit na tom sistemu.

Dodatno, većina rootkits-a su ’’istrajni’’, budući da ostale vrste malware-a nisu. Istrajnost se ogleda u tome što rootkits-i ostaju instalirani bez obzira na to koliko puta se sistem na koji su instalirani boot-uje. Neistrajni rootkits-i (takođe zvani ’’memory-resident’’ rootkits) nalaze se samo u memoriji; ni jedan file u kompromitovanom sistemu ne sadrži njihov kod. Oni zato ostaju u žrtvinom sistemu samo dok se sistem sledeci put ne boot-uje, kada se i brišu.

Kako rootkits rade Rootkits rade koristeći dva osnovna tipa mehanizma, onaj koji im omogućava da izbegnu detekciju i onaj koji

postavlja backdoors, kako je i objašnjeno u ovom delu.

Mehanizmi za sakrivanje Napadači znaju da otkrivanje njihovih nedozvoljenih aktivnosti na žrtvinom sistemu skoro stalno vodi istraživanju

koje rezultuje time da se sistem patch-uje ili ponovo ’’radi’’, čime ih efektivno tera da ’’počnu od početka’’ u njihovim


V01.2009

Page 72

naporima da dobiju nedozvoljen pristup i kontrolu ciljanog sistema ili, u najgorem slučaju za napadača, da istraživači dobiju tragove koji se mogu iskoristiti u indentifikaciji i na kraju osuđivanju napadača zbog loših namera. Zato ide u napadačevu prednost da sakrije sve indikacije o svom prisustvu na žrtvinom kompijeteru. Većina rootkits-a ima ugrađen jedan ili više mehanizma za sakrivanje – kao pravilo, što je više sofisticiran rootkit, to su više mehanizama deo njega i samim tim oni su veštiji.

Najosnovniji tip mehanizma za sakrivanje je onaj u kome se log podaci koji se odnose na napadačeve log-in-ove i log-out-e na žrtvinom sistemu brišu tako da kada sistem administratori ispituju sistemski bilans log-ovanja, oni ne vide bilo kakve ulaze koji bi izveštavali o tome da se napadač log-ovao u, ili iz, sistema ili bilo šta drugo uradio u njemu. Dodatno, mnogo rootkits-a brišu bilo kakve dokaze o procesima stvorenim od strane napadača ili samog rootkit-a. Kada administratori sistema unesu komande ili koriste sistemske opcije koje prikazuju procese koji su u toku, imena procesa započetih u vezi sa svim činjenicama o napadu (uključujući prisustvo rootkit-a) su izostavljena iz output-a. Rootkits takođe mogu da sakriju file-ove i directory-ume koje je napadač napravio na mnogo načina, uključujući menjanje komandi korišćenih za listanje sadržaja directory-uma da bi izostavile file-ove koje je napadač napravio ili (kao što je uskoro detaljnije objašnjeno) pravljenje promena na jezgru samog operativnog sistema uzrokujući da obezbeđuje netačne informacije o prisustvu i funkciji određenih file-ova i executables-a. Da bi dozvolili backdoor pristup napadačima, rootkits skoro uvek otvore jedan ili više mrežnih port-ova na žrtvinom sistemu. Da bi isključili verovatnoću otkrivanja rootkit-a kada administratori sistema ispituju otvorene (’’listening’’) port-ove, mnogi rootkits zato sakrivaju informacije o stanju određenih port-ova. Dodatno, neki rootkit-i menjaju šta se dešava kad su određene executables pokrenute od strane legitimnih korisnika (npr. administratora sistema) tako što se umesto orginalnih startuju zlonamerne executables koje površinski deluju da rade kao orginalne. Na kraju, neki rootkits (npr. oni sa sposobnošću log-ovanja preko tastature) uhvate ili izmene informacije poslate prema ili od strane hardware uređaja povezanog sa žrtvinim sistemom.

Backdoor mehanizmi Rootkits skoro bez izuzetaka snabdevaju napadače sa daljinskim backdoor pristupom kompromitovanih sistema.

Jedan od najopštijih načina za snabdevanjem ovom vrstom pristupa je kreiranje šifrovanih konekcija kao sto su secure shell (SSH) konekcije koje ne samo da daju napadačima daljinsku kontrolu nad kompromitovanim sistemima, već i šifruju informacije da bi onemogućili njihovu dostupnost za analizu od strane network-based intrusion detection systems (IDSs) i intrusion prevention systems (IPSs) kao i network monitoring tools-a. Dodatno, SSH implementacije korišćene u vezi sa rootkits-ima zahtevaju unošenje username i password-a, čime pospešuju zabranu korišćenja tog backdoor-a pojedincima koji ga nisu instalirali.

Tipovi rootkit-a Postoje dva osnovna tipa rootkit-a, used-mode rootkits i kernel-mode rootkits. Razlika je bazirana na nivoima na

kojima rade i tipu software-a na kojima vrše izmene ili zamenu. Ovaj odeljak opisuje oba tipa i objašnjava kako koji radi.

User-mode rootkits User-mode rootkits vrše zamenu executables i sistemskih datoteka koje administratori sistema i korisnici koriste. SSH

program i C datoteka u UNIX i Linux sistemima su dve najčešće mete. Windows Explorer (the default shell u Windows sistemima) je najčešće ciljana meta od strane user-mode rootkits-a. Tvorac user-mode rootkits-a veoma brine o tome da sakrije činjenicu da su executables i sistemske datoteke promenjene. Na primer, ako je rootkit zamenio SSH program, obe stvari, zadnji datum modifikacije i veličina file-a, će biti ono što su bile kada je SSH program orginalno instaliran kada administratori sistema unesu komande za traženje tih informacija. Dodatno, većina rootkits-a cilja samo nekoliko executables-a i sistemskih datoteka (obično samo jednu); što je manje executables-a i sistemskih datoteka ciljano, manja je i verovatnoća da će administratori sistema i korisnici primetiti da nešto nije u redu.

Kernel-mode rootkits Kao što njihovo ime implicira, kernel-mode rootkits menjaju delove unutar jezgra (Kernel) operativnog sistema na

žrtvinoj mašini ili ponekad kompletno zamene jezgro. Jezgro je srce operativnog sistema; snabdeva sve delove operativnog sistema osnovnim servisima (npr. kontrola ulaza i izlaza).

Kernel-mode rootkits sakrivaju prisustvo napadača bolje od user-mode rootkits-a. Administratori i programeri sistema veruju sadržaju kernel-level procesa, ali sve sto ima kontrolu nad jezgrom može prouzrokovati da procesi koji dolaze iz jezgra daju lažne informacije o svom statusu. Administratori i programeri sistema neće imati nikakve razloge da veruju da je ova informacija sumnjiva. Dodatno, detekcija promena na jezgru je generalno veoma teška, naročito ako su kernel-mode rootkits razvijeni od strane pojedinaca sa ekstremno visokim nivoima znanja i iskustva. Samim tim kernel-mode rootkits su mnogo opasniji od user-mode rootkits.


V01.2009

Page 73

Kernel-mode rootkits nepovrativo menjaju liste procesa da bi isključili procese koji rade u vezi sa rootkits-ima. Jezgro je svesno svih procesa koji rade, ali kada administratori sistema unesu komandu za listanje svih procesa,određeni (oni koje autor rootkit-a želi da sakrije) su izostavljeni kada jezgro da informacije o njima na zahtevanu komandu. Dodatno, kernel-mode rootkits često preusmeravaju egzekuciju programa tako da kada administratori sistema ili korisnici pokrenu određen program, potpuno drugačiji program se pokrene, a to je nešto što se zove ’’preusmeravanje’’ (’’redirection’’). Preusmeravanje je specijalno efektivna tehnika za sakrivanje zato što orginalan program ostaje netaknut; tako da se nikakve promene u tom programu ne mogu otkriti.

Razlika izmedju rootkits-a i drugih tipova zlonamernih programa Kao što je rečeno u definiciji na početku ovog poglavlja, rootkit je tip Trojan horse programa. Termin ’’Trojan horse

program’’ se u stvari odnosi na širok spektar skrivenih zlonamernih programa; tako da su rootkits jedna vrsta Trojan programa. Rootkits, međutim, idu dalje od konvencionalnih Trojan-aca u tome da su zadnji dizajnirani da prođu neprimećeni, ali ne objedinjuju aktivne mehanizme koji ih sprečavaju da budu otkriveni. Generalno gledano, primarni metod sakrivanja Trojan horse programa je dodeljivanje im bezopasnih imena (npr. ’’datafile’’ ili ’’misc’’). Za razliku, rootkits imaju mehanizme koji aktivno sakrivaju njihovo prisustvo od antivirus i antispyware programa, system management utilities-a i system and network administratora. Dodatno, Trojan programi su generalno kreirani unutar sistema koji su kompromitovani, to jest, oni ne vrše zamenu postojećih programa i file-ova, već su to novi programi koji su instalirani. Kao što je predhodno pomenuto, rootkits zapravo vrše zamenu programa operativnog sistema i sistemskih datoteka.

Takođe je važno da se razume da rootkits nisu alati koji iskorišćavaju ranljivosti. Instalacija rootkit-a zapravo zahteva da se jedna ili više ranljivosti prvo ispita. Dodatno, rootkits nisu virusi ili crvi, od kojih su oba programa samo-reproduktivna. Kad bi rootkits bili samo-reproduktivni, njihova detekcija i brisanje bili bi značajno lakši; autori rootkit-a zato izbegavaju ugrađivanje samo-reproduktivne funkcionalnosti u kod koji pišu.

Instalacija rootkits-a Jedan od najčešcih načina za instalaciju rootkits-a uključuje to da neko download-uje nesto sto izgleda kao patch ili

neki legitimni freeware ili shareware program, ali koji je u stvarnosti rootkit. Software je ponekad modifikovan na izvoru, programeri mogu ubaciti zlonamerne redove koda u program koji pišu. Skoriji primer toga je Sony BMG Music Entertainment copy-protection scheme, koja je došla uz muzičke kompakt diskove koji su tajno instalirali rootkit na kompijutere (više o tome u plavim redovima koji slede). Dodatno, zlonamerni Web serveri često instaliraju rootkits na sisteme tako što iskorišćavaju ranljivosti u browser-ima kao što su Internet Explorer i Mozilla Firefox koji dozvoljavaju zlonamernim Web stranicama da download-uju file-ove po prestupnikovom izboru ili u zlonamernom Web serveru davanjem procesima koje koriste ovi browser-i superuser privilegije na sistemu.

Relativno nov vektor napada za instalaciju rootkits-a je spyware. Skorašnji primer ovoga je varijacija VX2.Look2Me spyware Trojan pušten u novembru 2005 (pogledati na http://www.f-secure.com/sw-desc/look2me.shtml). Rootkits omogućavaju autorima spyware-a da sakriju podešavanja konfiguracije i programskih file-ova, dozvoljavajući samim rootkits-ima da budu instalirani u alternativnim tokovima podataka – opcijama vezanim za file-ove i directory-ume u Windows NT File System-u koje pružaju kompatibilnost sa Macintosh File System-om – da bi prikrili njihovo prisustvo. Kombinacije spyware-a i rootkit-a su tipično instalirane na žrtvin kompijuter preko zlonamernih Web stranica ili e-mail poruka koje iskorišćavaju ranljivosti Web browser-a ili koriste ’’social engineering’’ trikove da bi naterali korisnike da bez ikakvog znanja instaliraju kod.

Iako većina virusa i crva ne instalira rootkits, neki i to rade.

_________________________________________

Vendor-Installed Rootkits: Više razloga za brigu

Zajednice za sigurnost informacija uopšte kao i pojedini vendori (prodavci) sigurnosti sporo su reagovali na rizike vezane za rootkit-e. Skorije su, međutim, nekoliko vendora instalirali monitoring software koji koristi stealthy, rootkit-style tehnike da se sakrije. Davno pre nego što je Mark Russinovich dunuo u pištaljku na Sony BMG-ovo korišćenje takvog software-a koji sakriva svoja digitalna prava menagement scheme-om, spyware istraživači su videli tragove Sony BMG-ove kontraverzne tehnologije na personalnim kompijuterima ali nisu znali o čemu se radi. Kako je Russinovich objasnio, detekcija Sony BMG-ovog rootkit-a nije bio pravolinijski zadatak. Nove tehnike i produkti se pojavljuju da olakšaju tehničkom osoblju da identifikuju rootkits-e na kompromitovanim mašinama, ali kao prvo indetifikacija takvih mašina a kasnije i uklanjanje zlonamernog software-a ostaje frustrirajuće teško. Svi očekuju da zajednica prestupnika piše i razvija rootkits-e – prema McAfee-u, korišćenje stealth tehnika u malware-u je povećano za preko 600 posto od 2004. god. U isto vreme, ko bi očekivao da vendori pišu i instaliraju rootkits-e u svoje proizvode? Vendori kao što su Sony BMG su zato dodali još jedan sloj kompleksnosti na već previše složen rootkit problem.


V01.2009

Page 74

4.3.3 Rootkits i rizici vezani za sigurnost Rootkits su značajno podigli nivo rizika vezanih za sigurnost sa kojima se organizacije susreću, uglavnom

povećavajući troškove incidenata, povećavanjem verovatnoće backdoor pristupa, stavljajući mašine organizacija u rizik da postanu deo botnet-a i izlaganje organizacije riziku sigurnog preloma zbog neautorizovane zaplene informacija, kao što je objašnjeno u sledećim odeljcima.

Eskalacija cene vezane za proboj sigurnosti Premda rootkits ne upadaju u sistem sami od sebe, kad se jednom instaliraju na sistem (osim ako su loše dizajnirani

ili napisani) obično ih je ekstremno teško indetifikovati. Mogu se nalaziti na kompromitovanim sistemima čak mesecima a da niko, uključujući i najiskusnijeg administratora sistema, ne posumnja da nešto nije u redu. Troškovi proboja sigurnosti su proporcionalni njihovom trajanju; sve sto povećava trajanje na kraju povećava i troškove vezane za incident.

Povećana verovatnoća backdoor pristupa Pošto rootkits obično sadrže backdoors, oni znatno podižu verovatnoću da iako su efektivne siguronosne mere na

mestu, napadači će dobiti nedozvoljen daljinski pristup sistemu. Zbog toga što je rootkits-e teško otkriti, ko god da dobije takav pristup može preturati kroz sadržaj file-ova kompromitovanog sistema sakupljajući osetljive i druge informacije. Činjenica da pristup ovakve prirode je normalno na nivou superuser privilegija znači ne samo da napadači mogu daljinski pristupiti sistemu po svojoj volji, već takođe mogu imati potpunu kontrolu da rade šta god požele sa svakim sistemom kome imaju pristup.

Rootkits često rade u konekciji sa botnets Bot je zlonamerni executable koji je pod kontrolom glavnog programa koji koristi napadač da bi postigao mnoštvo

zlonamernih ciljeva. Botnet sadrži mnoštvo bot-ova koji se odazivaju centralnom izvoru kontrole. Botnets se mogu iskoristiti za mnogobrojne koristoljubive svrhe; jedna od najgorih je distribucija denial-of-service napada. Neki rootkits funkcionišu kao bot-ovi unutar masivnog botnet-a koji, ako se ne otkrije, može prouzrokovati štetne ishode. Ako su bot-ovi otkriveni dovoljno rano, mogu se istrebiti bez pružanja potrebnog vremena da ostvare svoje ciljeve, ali normalno rootkits je ekstremno teško naći, što skraćuje verovatnoću otkrivanja i brisanja bot-ova pre nego što izvrše svoja koristoljubiva dela.

Rootkits često sadrže keystroke and terminal loggers Još jedno područje rizika koji rootkits mogu predstavljati je zaplena osetljivih informacija kao što su brojevi kreditnih

kartica i lični indetifikacioni brojevi korišćeni u bankarskim transakcijama od strane keystroke and terminal loggers koji su deo rootkit-a. Keystroke loggers hvataju svaki karakter unešen u sistem, dok terminal loggers (koji predstavljaju još veći rizik od keystroke loggers) hvataju sve ulaze i izlaze, a ne samo one preko tastature. Keystroke and terminal loggers se često koriste u vezi sa identitetom lopova. Dodatno, keystroke and terminal loggers se često koriste da kradu log-on dokumenta, samim tim omogućavajući uspešne napade na sisteme koji koriste ta dokumenta. Keystroke and terminal loggers mogu takodje skupljati ključeve za šifrovanje, tako omogućavajući uspešne napade kriptoanalizom koji rezultuju mogućnošću dešifrovanja šifrovanih informacija.

4.3.4 Tehnike prevencije i zaštite od Rootkitaa Prevencija je najbolji lek; usvojiti mere koje sprečavaju rootkits da budu instalirani je mnogo bolje od njihovog

otkrivanja i istrebljivanja pošto su instalirani. Na neki način termin ’’rootkit prevencija’’ nema smisla jer je rootkit instalacija nešto sto se dešava pošto je sistem kompromitovan na superuser nivou. Jedan od bitnih elemenata u sprešavanju instalacije rootkits-a je čuvanje sistema da na prvom mestu i budu kompromitovani. Neki načini koji ostvaruju ovaj cilj uključuju korišćenje preventivnih mera, korišćenje software-a koji otkriva i briše rootkits, patch management, odgovarajuće konfigurisanje sistema, doslednost least privilege principle-u, korišćenje firewall-ova, korišćenje jake autentifikacije, praktikovanje dobrog održavanja sigurnosti i limiting compilers.

Profilaktične mere Profilaktične mere su mere koje sprečavaju instalaciju rookits-a, čak i kada napadač ima superuser privilegije. Izazov

stvaranja profilaktičnih mera koje pouzdano rade uprkos činjenici da napadač ima kontrolu nad operativnim sistemom kompromitovane mašine je veliki; zato ne treba doći kao iznenađenje to što trenutno postoji samo nekoliko takvih mera. Prevencija upada je obećavajuća profilaktična mera. Sistemi prevencije host-based upada, IPSs koji radi na individualnim sistemima, mogu sprečiti instalaciju rootkits-a preko policy files-a koji omogućavaju ili zabranjuju egzekuciju određenih komandi i sprečavaju zahteve servera da budu proizvedeni ako potencialno vode rootkit instalaciji ili drugim neželjenim ishodima. Dodatno, vendori operativnih sistema počinju da ugrađuju profilaktične mere u svoje produkte. Microsoft, na


V01.2009

Page 75

primer, je predstavio siguronosnu karakteristiku zvanu ’’Kernel Patch Protection’’ ili ’’PatchGuard’’ u 64-bit-nim verzijama svog Windows operativnog sistema. PatchGuard nadgleda jezgro i detektuje i zaustavlja pokušaje koda koji nije deo operativnog sistema da presretne i modifikuje kod jezgra. IPSs može na prvom mestu zaustaviti instalaciju rootkits-a, naravno, podrazumevajući, da svaki IPS ima updated policy file koji omogućava sistemu na kome se nalazi da zabrani odgovarajuće vrste dolazećih zahteva servera koji vode instalaciji rootkits-a.

4.3.5 Patch management Primena patches (zakrpa) koji zatvaraju slabe tačke je jedna od najvažnijih mera u sprečavanju instalacije rootkits-a.

Kao što je već napomenuto, napadči moraju da iskoriste slabe tačke i instaliraju rootkits-e, a potom ih i stave u rad uz pomoć superuser privilegija. Ako su sistemski i mrežni uređaji up to date sa dobrim patch-evima, napadači neće biti u mogućnosti da iskoriste slabe tačke i zato neće moći da instaliraju rootkits. Patch management alati koji automatizuju patching procese generalno obezbeđuju najefikasniji način za patch sistema. Naročito je strogo važno da svi patches dođu sa znanog, poverljivog izvora i da melanžna vrednost za svaki download-ovani patch bude jednaka vrednosti postavljenoj od strane njegovog proizvođača.

Prikladna konfiguracija sistema i limiting usluge koje rade na sistemima Da bi sprečili napadače da instaliraju system administrator-mode rootkits na sistem, korisnik mora očvrsnuti svaki

sistem tako što će ga konfigurisati prema priručniku za konfigurisanje sigurnosti. Vendori kao što su Microsoft i Sun Microsystems objavljuju takve priručnike za svaku verziju koju naprave, a i site-ovi kao što su Center for Internet Security nude priručnike kao i automatizovane alate da ’’ocene’’ kompijuter da bi videli koliko je siguran na osnovu njihovih priručnika. Mnogi tipovi malware-a iskorišćavaju usluge i software koji rade na client ili server mašinama. Neke usluge su ponekad uključene po default-u i rade bez korisnikovog znanja, ili su ostavljene uključene zbog loše security policy, ili su kasnije uključene. Organizacije bi trebalo imati default-nu konfiguraciju za clients i servers koja specificira usluge i software koji jesu i koji nisu potrebni i osigura ne samo da se te usluge isključe kad nisu potrebne,već i da se izvršni programi za sve nepotrebne usluge deinstaliraju, ako je moguće. Osiguravanjem da na mašinama rade samo one usluge i software koji su nužni za zadatke vezane za posao, organizacije mogu redukovati rootkit pretnju.

Doslednost primene principa dodeljivanja najmenjih privilegija novom korisniku Dodeljivanjem novim korisnicima sistema minimalan nivo privilegija koje su im potrebne da bi obavili posao

pomaže da se smanji verovatnoća da će napadači dobiti superuser privilegije, što znači da se smanjuje verovatnoća da će napadači instalirati rootkits. Na primer, kernel-level rootkits skoro uvek zahtevaju driver-e koji rade u kernel mode-u. U Windows operativnom sistemu, ovi driver-i se mogu učitati i ispisati iz memorije tehnikama sličnim onim potrebnim za stvaranje, omogućavanje ili terminaciju usluga. Samo je korisnicima sa administratorskim i sistemskim pravima (privilegijama) dozvoljeno da instaliraju programe (uključujući rootkits) koji rade u vezi sa driver-ima ili koji kreiraju usluge. Ako napadač koji ima nameru da instalira rootkit ne poseduje makar jednu od ove dve privilegije, rootkits se ne mogu startivati i shodno tome ne mogu se ni sakriti.

2.4.5 Postavljanje i konfigurisanje firewall-ova Firewalls mogu takođe obezbediti neke mere proaktivne zaštite od instalacije rootkit-a. Rootkits su specijalne

aplikacije korišćene od strane prestupnika. Zbog toga što firewalls sve više obavljaju analize mrežnog saobraćaja na aplikacionom sloju (network layer 7) umesto na mrežnom sloju (network layer 3), firewalls mogu unaprediti sposobnost da indetifikuju i presretnu zlonameran saobraćaj koji je u vezi sa rootkits-ima. Mnogi perimetar-based rootkits sada sadrže potpise aplikacionog sloja za poznati malware i skeniranje nadolazećeg saobraćaja od početka, tražeći sumnjive file-ove download-ovane od strane korisnika pre nego što se oni startuju na korisničkoj mašini. Mnogi proxy-based firewalls (firewalls koji prekidaju svaku nadolazeću konekciju a onda kreiraju novu outbound konekciju sa istim konekcionim karakteristikama ako konekcija udovoljava jednom ili više siguronosnih kriterijuma) sada uključuju skeniranje engines-a što povećava verovatnoću da sadržaj vezan za rootkit saobraćaj bude presreten pre nego što se download-uje i izvrši. U isto vreme, međutim, ova dodatna firewall funkcionalnost ima potencijalni efekat brisanja štetnog mrežnog delovanja. Profesionalci koji se bave sigurnošću informacija moraju zato balansirati upotrebu real-time skeniranja mreže za zlonamernim saobraćajajem sa obzirom na mrežne performanse.

Korišćenje čvrste autentifikacije Široka upotreba statičnih password-a u autentifikaciji sačinjava ozbiljnu ranljivost, onu koju napadač i zlonamerni

kod često iskorišćavaju da instaliraju rootkits na sisteme. Jaka autentičnost predstavlja korišćenje metoda autentičnosti koje je značajno teže razbiti. U primere metoda jake autentičnosti se uključuje korišćenje jednovremenskih password-a, simboli autentičnosti i biometric autentifikacija. Snaga autentifikacije u oba clients i servers slučaja može takođe biti poboljšana zahtevima za autentičnost na opšte-otvorenim uslugama i port-ovima. Korišćenjem otvorenih standarda kao što su IPSec


V01.2009

Page 76

protokol (koji definiše autentičnost zaglavlja za pakete poslate preko mreže, čuva od prevara i enkapsulacije sigurnosti korisnog tereta, pomaže osiguravanju poverljivosti sadržaja paketa) bitno se smanjuje verovatnoća ugrožavanja. IPSec je dostupan na Windows, Linux i UNIX platformama; mnogobrojni pristupi upravi za dokumente kao sto su shared key, Kerberos i public key infrastructure (PKI) mogu biti implementirani. Shared-key šema je najjednostavnija, ali najlakše ugrožljiva. Kerberos, veoma jak metod mrežne autentifikacije, je sigurniji od shared-key šeme, ali je izazovno njegovo razvijanje u heterogenom okruženju. PKI radi najbolje u heterogenom okruženju i najsigurniji je metod za autentifikaciju, ali zahteva i najviše vremena i truda. Partikularan IPSec pristup koji je najbolji zavisi od specifičnih potreba i poslovnih pokretača unutar svake organizacije.

Održavanja sigurnosti na sistemima Sve predhodno pomenute mere ne znače ništa ako se sistemi nisu up to date i ako se propisno ne održavaju. Veliki deo

održavanja sistema zato uključuje osiguranje da sistemska sigurnost ne propadne tokom vremena. Patch management, o kome je diskutovano ranije u ovom odeljku, je važan deo održavanja sigurnosti, ali to održavanje sigurnosti takođe zahteva mnogo aktivnosti kao dodatak patch management-u. Organizacije bi trebalo, na primer, da imaju centralizovanu polisu revizije koja bi omogućavala da administratori sistema redovno ispituju i analiziraju log-ovanja svakog kompijutera u njihovoj mreži.2 Jednako važno je i redovno ispitivanje sistema da se bude sigurno da kritična podešavanja koja imaju uticaj na sigurnost ne budu modifikovana bez dozvole i takođe da nikakvi novi računi (bez obzira da li su privilegovani ili ne) ne budu kreirani. Takođe je i dobra vežba da se vrše redovni pregledi sigurnosti da se vidi koje su mašine najranljivije za napad i ugrožavanje. Dodatno, za kritične sisteme, razvijanje alata kao što su Tripwire koji redovno vrši proveru za mogućim neautorizovanim promenama integriteta file-ova i directory-uma je važan deo održavanja sigurnosti. Obavljanje zadataka vezanih za ranljivost, uključujući periodično unutrašnje i spoljašnje testiranje penetracije, je još jedna komponenta održavanja sigurnosti.

Ograničavanje dostupnosti kompajlera Rootkits su postali kompleksniji tokom vremena. Iako je povećana kompleksnost rezultirala mnogim prednostima za

napadača, takođe je znatno više iskomplikovala instalaciju rootkit-a. Veliki broj rootkits-a se sada sastoji od mnogo komponenti kojima je potrebno da budu kompajlirane i instalirane, a to su koraci koji ako obavljeni ručno zahtevaju značajno više vremena što povećava verovatnoću detekcije. Zato sve veći broj rootkit-a sada sadrži easy-to-use instalacione skripte zvane ’’makefiles’’, instrukcije za kompajliranje i instaliranje programa. Makefiles navodi programske module i direktorijume da budu povezani i takođe sadrži specijalna uputstva koja dozvoljavaju određenim modulima da budu kompajlirani drugačije ako je to potrebno. Makefiles zahteva da kompajleri budu instalirani na sisteme; ako se kompajleri ne nalaze na sistemu koji je uspešno napadnut, napadači ih moraju prvo instalirati, a to je nešto što povećava vreme potrebno za instalaciju rootkit-a. Ograničavanje kompajlera tako da su instalirani samo na sistemima gde su potrebni za funkcije vezane za posao je još jedna efektivna mera protiv instalacije rootkit-a.

4.3.6 Definisanje politike odgovora na incident Odgovaranje na incidente vezane za sigurnost je često komplikovano, ali prisustvo rootkit-a čini odgovaranje na

incident još težim. Odgovor na incident sadrži šest faza: priprema, detekcija, zarobljivanje, uništavanje, oporavljanje i nastavljanje dalje. Neke od ovih faza, detekcija, uništavanje i oporavljanje, postaju veoma kompleksni nakon instalacije rootkits-a na žrtvine sisteme.

Detekcija Kao što je predhodno rečeno, otkrivanje većine rootkits-a je teško zbog mnogo informacija o napadima što vodi

brisanju i potiskivanju njihovih instalacija; zato su značajno vreme, trud i tehnička snaga mnogo potrebni. U svakom slučaju, postoji jedna utešna misao, ni jedan napadač ili rootkit , bez obzira koliko vešt bio, nije sposoban da sakrije baš sve informacije o napadu, uključujući prisustvo rootkit-a koji je instaliran. Jedan ili više tragova, bez obzira koliko mali, će biti dostupni ako vešti ispitivači i pogodni alati za analizu budu dostupni. Među tragovima koji bi verovatno bili dostupni su lagane promene sistema, izlaz alata za detekciju rootkit-a i izlaz alata za nadgledanje mreže.

2 - Ispitivanje bilansa log izlaza je osnovna stvar pri održavanju sigurnosti, iako takvi izlazi verovatno neće biti od

koristi pri pronalaženju rootkits-a zato što mehanizmi za sakrivanje u rootkits-ima skoro uvek brišu ili potiskaju bilo kakav bilans log upisa koji bi ukazivali na prisustvo napadača. Ispitivanje izlaza od strane security event management (SEM) alata koji sakupljaju širok spektar izlaza iz mnogo izvora i onda primenjuju slučaj algoritama uzajamnih veza da indentifikuju sumnjive događaje kao što su aktivnosti vezane za rootkits je veoma kompleksno.


V01.2009

Page 77

Promena detekcije Neobjašnjive promene u sistemu su indikatori odličnog potencijala za prisustvo rootkits-a. Promene u broju byt-ova u

file-ovima i directory-umima od jednog perioda vremena do drugog, na primer, ukazuju na prisustvo rootkit-a. Međutim, skoro svaki rootkit pokušava da potisne bilo kakvu indikaciju takvih promena tako da kada je data komanda za listanje sadržaja directory-uma, veličina file-a koji sada sadrži rootkit izgleda ista. Predpostavimo da je rootkit promenio veličinu izvršnog programa u UNIX sistemu, ali je takođe promenio ls – al komandu (komanda korišćena da listanje svih file-ova unutar directory-uma, njihova veličina, kome pripadaju itd.) tako da izlaz ove komande lažno prikazuje da je sadržaj file-a koji sadrži izvršni program ostao nepromenjen. Rešenje za profesionalce koji se bave sigurnošću informacija je da se izbore za izlaz melanžnog algoritma kao što je Secure Hash Algorithm version 1 (SHA1) od jednog trenutka u vremenu do drugog. Ako se pojave bilo kakve promene u sadržaju file-a, obračunata melanžna vrednost će se promeniti. Sa razumljivo jakim melanžnim algoritmom, postoje male šanse da neko može izvršiti promene na file-u bez da melanžna vrednost za promenjeni file bude drugačija. Ako rootkit nekako maskira SHA1 melanžnu vrednost promene koja je nastala menjanjem izvršnog programa, ta promena će sigurno biti detektovana uporedjivanjem melanžnih vrednosti pre i posle promene nekim drugim melanžnim algoritmom, kao što je Message Digest algorithm version 5 (MD5). Zapravo je nemoguće prevariti višestruk broj melanžnih algoritama promenom sadržaja samo jednog file-a, pod uslovom da su algoritmi dovoljno jaki protiv napada kriptoanalizom. Koristeći alate kao što su Tripwire, koji sadrže više melanžnih vrednosti kao i nekoliko crypto checksums-a kao i druge vrednosti za detekciju promena u file-ovima i directory-umima, je jedan od najmoćnijih načina za detekciju prisustva rootkits-a.

Malo je verovatno ali ne i nemoguće za iskusne administratore sistema i sistemske programere da primete promene prouzrokovane rootkit-om bez korišćenja specijalnih alata, od kojih je Tripwire samo jedan. Host-based IDSs mogu takođe primetiti sumnjive promene koje mogu ukazati na prisustvo rootkits-a, a mogu i alati administratora sistema kao što su Tivoli and Unicenter TNG. Lsof komanda, u UNIX i Linux,a i fport, Windows alat, obe listaju otvorene port-ove i procese koje su otvorili, mada kao što je predhodno pomenuto mnogi rootkits menjaju takve komande da bi potisnuli informacije o aktivnosti port-a. Forensics software može takođe biti koristan za detekciju promena u sistemima. Na kraju, bitno je da bilo kakva detekcija ili forensics alati i izlazni podaci na kojima alati mogu da budu offline (npr. na CD-u) se nalaze na fizički sigurnoj lokaciji do njihove upotrebe; ako se ostave na sistemu, mogu biti modifikovani od strane napadača koji je kompromitovao sistem na kome se nalaze.

Puštanje u rad alata dizajniranih za detekciju rootkit-a Upotreba alata koja je specijalno dizajnirana da trazi i uništava rootkit-e je još jedan moguć pristup problemu.

Besplatni alati kao što su chkrootkit (za Linux sisteme) i Rootkit Revealer (za Windows sisteme) generalno koriste mnoštvo mehanizama za detekciju da bi ostvarili svoje ciljeve. Ove alate je potrebno stalno update-ovati ako želimo da budu efektivni. Važno je za profesionalce koji se bave sigurnošću informacija da shvate da su ovi alati daleko od savršenstva; mnogi rootkits imaju mehanizme za sakrivanje koji su napredniji od sposobnosti alata za detekciju i uništenje rootkit-a.

Nažalost, antivirus i antispyware alati trenutno nisu u prednosti u detekciji Trojan horses-a, a kamoli rootkits-a, iz mnogo razloga. Prvo, pisci rootkit-a su svesni da njihovi alati moraju izbeći detekciju od strane antivirus i antispyware software-a i zato sadrže mehanizme unutar rootkit koda koji im omogućavaju da to urade. Dodatno, antivirus i antispyware software se u velikoj meri oslanja na potpise zlonamernog koda, binarnim ili karakternim nizovima koji razlikuju jedan deo zlonamernog koda od drugog dela, za detekciju. Mnogi od današnjih zlonamernih kodova, uključujući rootkits, koriste mnoštvo tehnika za izbegavanje detekcije potpisa. Dodatno, potpisi, čak i da rade u detekciji rootkits-a, su nepromenljivo post hoc prirode; potpisi se zato ne mogu koristiti da prepoznaju zlonameran kod koji je korišćen u zero-day exploits. U isto vreme rasteći broj vendora za antivirus software ugrađuju sposobnost skeniranja jezgra ili user-mode memorije za poznate rootkits-e. Donja crta je da trenutno, profesionalci koji se bave sigurnošću informacija ne treba da se uzdaju u antivirus i antispyware software za detekciju rootkits-a. Ako alati dizajnirani specijalno za detekciju rootkits-a nisu baš toliko vešti u svojoj svrsi (kao što je predhodno pomenuto), ne bi bilo iznenađenje da se shvati da su antivirus i antispyware software-i još gori.

Analiza izlaza alata za nadgledanje mreže Nadgledanje aktivnosti mreže je efikasan metod za detekciju rootkits-a, nalaženje konekcija koje imaju malo smisla,

na primer, konekcija između naplatnog servera velike korporacije i mašine sa domenom imena koje očigledno pripada univerzitetu, može navesti sistemske i mrežne administratore na istragu šta se to desilo sa naplatnim serverom. Ako istraga sistema koji je imao sumnjive konekcije dovede do otkrića da informacija o drugim konekcijama, onih koje nisu sumnjive,su dostupne u bilansu log podataka, prisustvo rootkit-a bi bilo veoma moguće objašnjenje. Aktivnost na određenim port-ovima je još jedna moguća indikacija rootkit-a. Iako je dokaz o takvoj aktivnosti verovatno sakriven na svakoj mašini na kojoj je instaliran rootkit, network-based IPSs, IDSs, SEM alati i firewalls će u svakom slučaju detektovati aktivnost vezanu za port što može ukazati na prisustvo rootkit-a na takvoj mašini. Oba network i host-based IDSs i IPSs mogu obezbediti informacije o pokušaju instalacije rootkits-a kao i prisustva rootkits-a na sistemu. Zbrajanje izlaza iz IPSs-a, IDSs-a, firewalls-a, routers-a, individualnih sistema i drugih izvora log podataka i njihovo upoređivanje korišćenjem software-a za upoređivanje takođe


V01.2009

Page 78

povećava verovatnoću detekcije rootkits-a na sistemima. Efektni rootkits-i ne ostavljaju očigledne indikatore svog postojanja, zato upoređeni tragovi (bez obzira koliko nejasni) iz više izvora o postojanju rootkits-a, su u stvari često najbolji način da se oni otkriju.

Uništavanje Uništavanje podrazumeva eliminaciju uzroka svakog incidenta. Ako je rootkit otkriven na sistemu, prvi impuls od

strane istrašivača je, normalno, brisanje rootkit-a što je pre moguće. Radeći to je obično nepravilan tok akcije. U najviše slučajeva mnogo je bolje da se napravi image backup, rezerva zapravo svega na hard drive-u kompromitovanog sistema (uključujući informacije koje su pažljivo sakrivene na drugim mestima osim u file-ovima), što je pre moguće. Radeći to biće omogućeno forensic ekspertima da izvedu temeljnu forensics analizu koja će im omogućiti da: (1) sačuvaju dokaze koje će potencijalno moći da iskoriste u kasnijim legalnim akcijama, (2) analiziraju mehanizme korišćene od strane rootkit-a i bilo koje druge zlonamerne alate koji su instalirani i (3) iskoriste informacije za identifikaciju drugih mašina koje mogu biti kompromitovane na bazi dokaza unutar samog kompromitovanog sistema. Treba zapamtiti – neki rootkits-i su nepostojani, tako da je trenutno pravljenje image backup-a kritičnije ako je neophodno napraviti kopiju rootkit-a.

A sada loše vesti – za razliku od virusa, crva i većeg broja Trojan horse programa, rootkits se često ne mogu ’hiruški’ odstraniti. Programi kao što su chkrootkit (pogledati na http://www.chkrootkit.org) i Rootkit Releaver (više informacije koje se mogu pogledati o njemu su na http://www.microsoft.com/technet/sysinternals/utilities/RootkitReleaver.mspx) bi mogli da obrišu rootkits, ali razmišljnja vezana za uništavanje rootkits-a su drugačija od onih vezanih za druge vrste malware-a. Rootkits, skoro bez izuzetaka, rade sa superuser privilegijama. Bilo kada da je sistem kompromitovan na superuser nivou, rootkit i napadač koji ga je instalirao mogu uraditi sistemu šta god požele. Otkrivanje svih promena i zamena software-a lako je verovatno da je to nemoguć posao, a i ako forensic eksperti previde makar i samo jednu promenu koja je napravljena, napadač i rootkit mogu ubrzo zatim povratiti kontrolu nad sistemom. Zbog toga je najbolja stvar da se ne reskira – treba samo ponovo uraditi sistem koristeći orginalne instalacije. Ako se to ne uradi tako ishod bi se mogao ogledati u ostanku zlonamernog koda ili neautorizovanih promena u kompromitovanom sistemu.

Oporavljanje Oporavljanje znači vraćanje kompromitovanog sistema na svoj normalni status rada. Opet, ako je rootkit instaliran na

kompromitovanom sistemu, ponovno rađenje sistema je skoro uvek najbolji tok akcije. Da bi se osiguralo da se rootkits i ostali malware ne pojave ponovo dok traje oporavljanje sistema, sistem se mora raditi korišćenjem orginalnih instalacija, a i podaci i programi moraju biti kao što su bili pre nego što se napad desio. Dodatno, bilo koji patch-evi koje je potrebno i treba instalirati da bi se osiguralo da sistem neće podleći istom napadu(ima) koji je predhodno lansiran protiv njega. Na kraju, pre nego što se proces oporavka može smatrati gotovim, treba se izvršiti skeniranje ranljivosti kompromitovanog sistema da bi se osiguralo da ni jedna unpatch ranljivost ne postoji.

4.3.7 Zaključak Rootkits predstavljaju veoma veliki nivo rizika za informacije i informacione sisteme. Profesionalci koji se bave

sigurnošću informacija potrebno je da temeljno nauče o i analizi rizika vezanih za rootkit i onda izaberu, implementiraju i testiraju odgovarajuće mere kontrole bezbednosti. Uspešna strategija kontrole rizika sadrži osuguranje da mnoštvo sistema i network-based mera kontrole bezbednosti, kao što su odgovarajuća konfiguracija sistema, obezbeđivanje sistemskih patch-eva, korišćenje jake autentifikacije, a i druge mere, su na mestu. Zato što su rootkits veoma vešti u svom sakrivanju, ekstremno jako nadgledanje i detekciju upada i prevencioni trud takođe treba implementirati. Čak šta više, efikasne procedure i mere za odgovor na incident služe kao još jedan cornerstone u bitci za minimizaciju štete i pometnje izazvane od strane rootkit-a.

U završnoj reči, profesionalci koji se bave sigurnošću informacija potrebno je da stave problem rootkits-a u pravu perspektivu. Rootkits su prvi put pronađeni 1994.; čak i u to vreme bili su izvanredno vešti u svom sakrivanju i kreiranju mehanizma za backdoor pristup. Od tog vremena, rootkits su napravili ogroman napredak do te tačke da mnoge od njih je skoro nemoguće detektovati. Neki od njih su bukvalno ’’sve u jednom’’ malware – kompletan arsenal oružja za napadača. Dodatno, mnogi današnji rootkits hvataju osetljive informacije i sposobni su da budu deo gigantskog botnet-a koji može kreirati masivne štete i pometnje. Donja crta je da kad se radi o rizicima vezanim za rootkits treba biti u prvom redu široko poznatog radara profesionalaca koji se bave sigurnošću informacija.


V01.2009

Page 79

4.4. Elementi fizičke sigurnosti 4.4.1 pojam ostvarivanja fizičke sigurnosti objekata Problem sa većinom sistema za kartice je tailgating. To je kao kad jedna osoba otključa vrata koristeći sigurusnu

karticu, a umesto jedne u osiguranu sobu uđe troje ljudi. Zavisno od kritičnosti osiguranog prostora ovo bi moglo biti neprihvatljivo.

Postoji mnogo nivoa kontrole pristupa, rangirajući se od nijednog do totalnog. Totalna kontrola implicira da svaka osoba koja ulazi i napušta prostorije je autorizovana, dodeljen joj je pristup i izlaz, i da je svako kršenje ovih pravila označeno stanjem alarma. Većina ustanova se fokusira na kontrolisanje ko može da udje u prostoriju kroz korišćenje jednog ili više nivoa autentifikacije: nešto što neko ima, što bi moglo biti obično kao ključ ili token kontrole pristupa izdat od kompanije (blizina, bezkontaktna pametna kartica, itd.); nešto što neko zna, što može biti obično kao četvorocifreni pin broj unešen u keypad (obično integrisan u čitač kartica); ili nešto što neko jeste, kao što je skeniranje otiska prsta ili mrežnjače. Za oblasti sa većom kontrolom pristupa, kombinacija dva ili čak sva tri nivoa bi se mogla opravdati.

Nivo pristupa bi trebao biti odgovarajući kritičnosti radnog prostora. Premda se ove tehnologije mogu efektivno koristiti za osiguranje sa velikim stepenom pouzdanja da samo autorizovane osobe mogu otvoriti vrata, ne rade ništa da osiguraju da neautorizovane osobe ne uđu za njima pre nego što se vrata zatvore. Mantraps i turnstiles se mogu iskoristiti da povećaju nivo kontrole i redukuju ili eleminišu tailgeting.

4.4.2 Mantraps Mantrap se koristi kad je poželjna veća kontrola za pristup, ali nije potrena totalna kontrola. Jedan razlog može biti

da je to ulaz u okruženje čiste sobe gde je potrebna kontaminacija. Mantrap se ostvaruje imanjem dvoja vrata, oba sa opremom za kontrolu pristupa. Vrata su udaljena jedna od drugih, obično oko četiri i po metra, tako da ima vremena da se prva vrata zatvore pre nego što se dođe do drugih. Ideja je da se ni jedna vrata ne mogu otvoriti dok su druga u otvorenom stanju, pa prema tome praveći nemogućim za nekog da se provuče unutra ili uleti u osiguranu oblast neproveren. Mantraps obično imaju kamere i na unutrašnjim i na spoljašnjim vratima i povezana su hodnikom, da se niko ne bi sakrio dok dobija ulaz i dozvolio više ljudi tu autorizaciju.

Mnoga stanja imaju požarna pravila koji zahtevaju da slobodan pristup bude dozvoljen iz svake osigurane oblasti obično zahtevajući ono što se zove ’’ne posebno znanje’’ da bi se izašlo. Ovo znači da kad neko treba da izađe napolje zbog požara, treba samo da pritisne neku easy-to-use kvaku ili crash bar da bi izašli. Zbog ovoga većina vrata koja koriste električni udar imaju slobodan izlaz povlačenjem poluge da ukinu udar i ne zahtevaju oslobađanje električnog udara za izlaženje. Ovo ne bi dalo pozitivnu konrolu koju mantrap zahteva, zato je bolje ili da se vrata drže fizički zatvorena ili da se koristi magnetska brava, koja drži vrata sigurnim dok se ne aktivira pločicim osetljivom na dodir za izlaz. Ovim načinom izlaženja, krug može biti prekinut svaki put kad su druga vrata otvorena, detektovano od strane vratnih kontakata postavljenim na oba vrata. Na ovaj način, pristup drugim vratima nije dozvoljen, tako praveći mantrap.

Ako osoba prati autorizovanog radnika kroz prva vrata, može im se odbiti ulazak u oblast sa ograničenim pristupom i moraće da izađu na spoljna vrata. Niko nije stvarno zarobljen u mantrap-u, zato što to sada zabranjuju protivpožarna pravila, ali opisana postavka štiti protiv navale osoba koje dobijaju pristup osiguranoj oblasti prateći radnika kroz jedna otvorena vrata direktno u ograničen prostor.

Varijacija ovoga je korišćena za konrolu prometa vozila u osiguranom prostoru. Postavka je slična gore opisanoj, ali sa više kontrole, zato što trake mogu biti podeljene na ulazne i izlazne, eliminisanjem šanse da neko dobije ulaz dok neko drugi izlazi. Dve kapije su odvojene razumnom daljinom da bi se dozvolilo samo jednom tipu bilo kojeg vozala da koristi to mesto. Ovo se može uraditi da bi se obavila inspekcija vozila ili da se eliminiše mogućnost tailgating-a. Za ekstremno kritične oblasti, barijere za vozila se mogu koristiti zajedno sa ili umesto tradicionalnih kapija da bi se osiguralo da ni jedno vozilo ne može da uće na silu.

4.5. Turnstiles Totalna kontrola se može zahtevati za ulaz u oblast za revizione svrhe, čak i za centre podataka sa Sarbanes-Oxley

potraživanjima, ali obično nije zahtevana za izlaz. Turnstile se može postaviti da dozvoli izlaz po slobodnoj volji. Turnstiles su produkt kontrole pristupa čija je svrha da osiguraju pozitivnu kontrolu pristupa. Samo jednoj osobi po transakciji je dozvoljen pristup, bilo da koriste token podzemne stanice ili siguronosno ovlašćenje da uđu u zgradu.

Postoje tri glavna tipa turnstiles-a: prvi je optički turnstile, koji ne nudi isti nivo kontrole pristupa koji bi bio zahtevan u nekim postavkama i često je pored njega radnik obezbeđenja (Slika 4.9 Optički turnstile sa barijerom).

Drugi tip su poboljšana rotirajuća vrata koja su kreirana sa mehanizmom koji će dozvoliti samo po jednom delu vrata da rotira u prostoriju sa ograničenim pristupom (Slika 4.10 Rotirajuća vrata).


V01.2009

Page 80

Zadnji je tradicionalni tip viđen u većini industrijskih postavki i primarno korišćen za aplikacije koje se nalaze napolju (Slika 4.11 Tradicionalni turnstile).

Slika 4.9 Optički turnstile sa barijerom

Slika 4.10 Rotirajuća vrata


V01.2009

Page 81

Slika 4.11 Tradicionalni turnstile

Optički turnstiles Članovi obezbeđenja su godinama bili korišćeni za kontrolu pristupa u mnogim kompanijama, ali čak i kad bi svaki

član obezbeđenja bio savršen i nikad ne prevideo osobu ili pomešao indentifikacionu karticu sa nekom drugom karticom za vreme visokog prometa, nema načina da on zna da li su svi ti ljudi i dalje zaposleni, samo da poseduju indentifikacionu karticu i da je njihovo lice na njoj. Optički turnstiles su dizajnirani da se smeste različiti tipovi akreditivnih ili biometričkih čitača da osiguraju da su svi koji ulaze i dalje aktivni u sistemu. Naravno, i dalje postoji ljudska greška, ako neko zaboravi da uključi neaktivan zapis u sistemu pristupa kartice, ali šansa za grešku je manja od oslanjanja na vizuelnu inspekciu. Praksa bi trebala da zahteva od upravnika da napravi formular za uklanjanje radnika iz baza podataka kada im poslovni ugovor istekne, a hitna praksa bi trebalo da bude momentalno ukidanje logičkog i fizičkog pristupa kada je otkaz uzrok. Tada ako ili osoba nema indetifikacionu karticu ili ako upravnik ili personal ljudskih resorsa zaboravi da je pogleda, neće se registrovati kao aktivna kartica i trebao bi da se začuje alrm. Na ovaj način kao i sa svim alarmima, profesionalci sigurnosti bi trebalo da provode svoje vreme reagujući na izuzetke a ne nadgledaju normalne ili autorizovane transakcije.

Optički turnstiles ne pružaju stvarno barijeru, jer su većinom visoki 91,44 cm i neki imaju male krilne barijere na šipkama da zaustave ulazak, dok druge jednostavno imaju alarm. Dizajnirani su za oblasti sa visokim prometom u kooperaciji sa članom obezbeđenja, gde je nepraktično da se oslanja na same članove obezbeđenja da izvrše vizuelnu proveru svake indetifikacione kartice. Tradicionalno su postavljene da alarmiraju samo kada je detektovano kretanje iz jednog pravca za ulazak bez validnog očitavanja kartice i da ignorišu kretanje pri izlasku, ali ako se želi mogu se namestiti da traže karticu i pri izlasku.

Rotirajuća vrata Rotirajuća vrata se takođe mogu postaviti za ili samo ulaznu ili i ulaznu i izlaznu kontrolu. Dobrobit od rotirajućih

vrata je da, za razliku od optičkih turnstil-a, mogu se podesiti da dozvole samo jednoj po jednoj osobi ulazak ili izlazak iz prostorije i ne može se zaobići. Mana rotirajućih vrata je da zbog tesne kontrole, vrata se sporo pomeraju i nisu preporučiva za oblasti visokog prometa. Najbolja mesta za njih su oblasti visoke ograničenosti gde je tailgating neprihvatljivo. Izlaz iz takve oblasti takođe može biti kompletno kontrolisan i prema tome praćen, ali zbog protivpožarnih pravila, u većini zemalja,


V01.2009

Page 82

rotirajuća vrata su dizajnirana sa razbijajućom opcijom koja ruši delove vrata da bi dozvolila hitan izlaz. Alarm bi rebalo da bude povezan sa vratima u slučaju da ih neko provali ne bi li izbegao zapis svog izlaska.

Tradicionalni turnstiles Postoje turnstiles koje većina ljudi zamisli kad čuje tu reč. Od metala su i najčešće se koriste u sportskim salama ili

parkinzima. Noviji modeli funkcionišu kao malopre opisana rotirajuća vrata, ali su dizajnirani za aplikacije koje se nalaze napolju.

Zato što svi tipovi turnstiles-a mogu zabeležiti sve ulaze u kontrolisano područje, postoje siguronosne dobiti koje se mogu iskoristiti kad su povezane sa većinom sistema pristupa koji koriste kartice. Opšta opcija koja se većinom ne koristi je opcija pregleda sistema pristupa koji koriste karticu. Opcija pregleda prati ko god da ulazi ili napušta specijalno područje. Da bi opcija radila, svako ko ulazi ili izlazi mora registrovati svoj token i pri ulasku i pri izlasku. Ako se ovo ne desi, software će pomisliti da je neko i dalje na tom mestu iako je u stvari prazno ili ne zapamtiti da su bili na mestu iako su u stvari unutra. Ova opcija je korisna za vreme evakuacije zbog požara ili hemijske katastrofe, kada je kritično da se dobije tačan broj onih koji su ostali unutar zgrade ili industrijskog kompleksa. Vatrogasci će rizikovati svoje živote ulazeći u te opasne oblasti i za njih je važno da znaju da li je dvoje ili desetoro ljudi ostalo unutra ili nije niko, jer tada uopšte ne bi postojao razlog da se ulazi.

Ako je opcija pregleda poželjna, onda je lokacija izlaznih čitača veoma važna i može zahtevati dodatne čitače na udaljenijim lokacijama da osigura siguran i brz izlaz. Zato, za normalne dnevne operacije, može postojati red od dva ili tri turnstiles-a na svakoj glavnoj ulaznoj tački sa čitačima kartica sa iznutrašnje i spoljašnje strane zida ograde područja, koji zahtevaju jedno čitanje kartice pri zahtevu za ulaz i izlaz. Za hitne slučajeve, mogu postojati dodatni čitači montirani na tačkama pregleda na sigurnoj udaljenosti od zgrade, a i turnstiles mogu biti povezani sa protivpožarnim sistemom i mogu imati ručno premošćivanje da bi dozvolili slobodan izlaz da ne bi bilo spore evakuacije. Onda na tački pregleda svaki radnik može registrovati svoju karticu zbog izlaska. Mnoge opcije sa pristupom uz pomoć kartice rade izveštaje svakih nekoliko minuta bazirano na predpostavkama za vreme događaja, svaki pokazujući manje i manje imena dok god se oblast ne isprazni ili ne prijave poslednjih nekoliko ljudi koji su ostali unutra.

Ako je ista opcija pregleda korišćena na više limitirajući način u, recimo, labaratoriji unutar velikog kompleksa, rotirajuća vrata bi se trebalo upotrebiti umesto tradicionalnog turnstile-a. Normalna operacija može takođe zahtevati neki oblik dozvoljenog pristupa koristeći credential ili biometric za ulaz i izlaz za daljinskim čitačem na sigurnoj udaljenosti, ako je pregled zahtevan, ili samo ulaz ako nije.

4.5.1 Zaključak Postoji mnogo tipova metodologija i tehnologija kontrole pristupa. Kao najviše rešenja vezanih za sigurnost, procena

rizika bi trebala biti urađena i napravljen zapis opisa onoga što se pokušava postići. Profesionalac bezbednosti ne bi nikad trebalo da izgubi iz vida orginalni cilj, iako se to može lako desiti u potrazi za rešenjem. Ako takva procena ukazuje da mora biti zaštite od tailgating-a veće od one koju jedna vrata pružaju, onda mantrap ili neka vrsta turnstile-a mogu biti odgovor. Ako nam treba pozitivna kontrola ulaza za revizije ili razloge vezane za životnu sigurnost, onda mogu biti zahtevani ili tradicionalni turnstile ili rotirajuća vrata (za aplikacije tipa kancelarije). Bez obzira na izbor produkta kontrole pristupa, rešenja koja zahtevaju ovaj nivo kontrole bi trebalo da budu uvek propraćena video nadzorom. Svaka kamera koja pokriva visok nivo kontrole pristupa bi trebalo da snima sve vreme i sa dovoljnom definicijom i brojem frejmova da bi se mogla napraviti pozitivna indentifikacija.

Bilo koji nivo kontrole da je zahtevan; postoje dostupni različiti produkti kontrole pristupa koji bi odgovarali takvim potrebama. Treba se biti siguran pre nego što se izabere da rešenje odgovara zahtevima prostorija sa ograničenim pristupom.

4.6. Aspekti sigurnosti u projektovanju aplikacija Koncept od service-oriented architecture (SOA) je postojao u različitim formama već neko vreme, ali je u zadnje

vreme SOA model stvarno postao popularan zbog napredovanja u Web tehnologiji, Web uslugama i standardima. Iako koncept SOA-e nije povezan sa nekom specifičnom tehnologijom, u najvećem broju slučajeva SOA se sada odnosi na distributivni sistem koristeći Web usluge za komunikaciju. Drugi primeri SOA arhitekture su primarno bazirani na daljinske procedure poziva, koji koriste binarne ili posedničke standarde koji predstavljaju izazov za unutrašnju operativnost. Web usluge rešavaju problem unutrašnje operativnosti zato što su bazirane na eXtensible Markup Language (XML), koji je po prirodi standard unutrašnje operativnosti. Značajan trud je uložen u razvijanje standarda sigurnosti Web usluga da bi omogućile integritet, poverenje, autentikacuju, uparene identitete itd. . Ovo poglavlje će se fokusirati na te standarde sigurnosti, od kojih će pokriti XML, XML enkripciju, XML potpis, Simple Object Access Protocol (SOAP), Security Assertion Markup Language (SAML), WS sigurnost i druge standarde u porodici WS sigurnosti.


V01.2009

Page 83

4.6.1 Uvod u principe kompijuterske i mrežne organizacije, arhitekture i dizajna Dakle šta je to SOA? SOA je model arhitekture baziran na nezavisnim (ili labavo uparenim) uslugama, sa dobro

dizajniranim interfejsom koji je dizajniran na takav način da podržava ponovnu upotrebu. SOA se ekstremno dobro slaže sa arhitekturama baziranim na Web uslugama, koje po prirodi odgovaraju definiciji labavog uparivanja i dobro definisanog interfejsa. Kao primer usluge u SOA, zamislimo korisnički direktorijum koji je dostupan preko Web usluga. U ovom primeru, interfejs može specifirati funkcije, ili metode, koje uključuju pretraživanje direktorijuma (SearchDirectory), resetovanje password-a (resetPassword), updating korisničkih informacija (updateUser) dodavanje ili uklanjanje korisnika (addUser, removeUser). Dok god je interfejs adekvatno definisan, potrošač usluga nema potrebe da zna kako su usluge implementirane da bi ih koristio. Slika 1 ilustruje pojednostavljenu SOA.

Slika 1 pokazuje da je svaka usluga razumno nezavisna i ima dobro definisanu svrhu. Ideja iza SOA-e je da, u slučaju da su usluge i njihovi interfejsi dobro definisani, se mogu kombinovati na različite načine da bi napravili različite tipove aplikacija. Na primer, order-processing usluzi se može pristupiti i sa javnog Web site-a za izdavanje naredbi i sa internacionalnog Web site-a za prodaju i marketing svrhe. Usluge ispoljavaju svoju funkcionalnost kroz interfejse Web usluga sa industrijskim standardom opisanim koristeći Web Services Description Language (WSDL), koji će kasnije u ovom poglavlju biti opisan.

U prostom primeru pomenutom ranije, sigurnost nije prikazana na slici Slika 4.12 Primer pojednostavljene SOA. Da bi se dodala sigurnost na tu sliku mora biti ispunjeno nešto od sledećeg:

• Sigurnost mreže, sigurnost operativnog sistema (server hardening), sigurnost aplikacija i fizička sigurnost

• Sigurnost transporta, tipično preko korišćenja Secure Sockets Layer (SSL)

• Sigurnost Web usluga kroz korišćenje standarda Web Service-Security porodice (WS-*) za obezbeđivanje poruka Web usluga

• Upotrebom drugih WS-Security ekstenzija za obezbeđivanje poverljivih veza između kompanije, dobavljača uplate i dobavljača transporta

Slika 4.12 Primer pojednostavljene SOA


V01.2009

Page 84

Standardi Web usluga i sigurnosti Web usluga mnogo koriste XML. XML ima revolucioniranu razmenu podataka zbog svoje jednostavnosti i moći. Kao jednostavan , čitljiv za ljude, tekstualni format XML je smestio razmenu podataka između aplikacija i poslova čak i kroz sisteme koji nisu slični.

Podsetnik ovog poglavlja diskutuje o Web uslugama i metodama korišćenim da se osiguraju aplikacije i podaci u SOA okruženju. Standardi kao što su XML, XML enkripcija, XML potpis, SOAP, SAML i sigurnosti Web usluga će takođe biti pokriveni kao deo ovog poglavlja.

4.6.2 Osnove Web usluga i sigurnosti Web usluga Web usluge i sigurnost Web usluga se baziraju na nekoliko standarda koje bi oni koji praktikuju sigurnost trebali da

razumeju do određene granice. Ideja je da se obezbedi pregled relevantnih standarda i način kako bi pristajali jedan drugom. Što se tiče nekih kompleksnijih standarda, o njima ćemo detaljnije u kasnijim poglavljima.

eXtensible Markup Language XML je osnovni blok za građenje uz pomoć koga su svi drugi standardi Web usluga i sigurnosti Web usluga građeni.

XML je besplatan, otvoren standard preporučen od World Wide Web Consortium-a (W3C) kao metod razmene podataka korišćenjem jednostavnog formata baziranog na tekstu. Činjenica je, da je XML jednostavan, čitljiv za ljude format i radi preko heterogenih sistema što ga čini savršenim za Web usluge i SOA-e za koje usluga i potrošač (klijent) mogu biti na različitim platformama.

Primer na slici Slika 4.13 Jednostavan XML primer je isečak XML-a koji opisuje osobu. Ovaj jednostavan primer pokazuje kako ljudsko biće može lako pročitati XML. Struktura XML-a jasno pokazuje ovo kao podatke vezane za osobu (pogledati elemente osobe na slici Slika 4.13). Dakle kao dodatak razmeni podataka, XML daje određeno razumevanje onog što podaci predstavljaju.

Slika 4.13 Jednostavan XML primer

XML ekstenzije Iako nije važno za razumevanje kako je XML povezan sa sigurnošću Web usluga, postoje neke ekstenzije XML-a koje

bi trebalo biti uključene u kompletiranje.

XML šema je važna ekstenzija koja dozvoljava strukturi XML-a da bude definisana slično načinu na koji je definisana šema SQL baze podataka. Između ostalog, XML šema specificira kakva treba da bude struktura XML-a, po kom redu bi elementi trebalo da se pojavljuju, koliko je kojih elemenata dozvoljeno i tipove podataka. XML šema je korisna za kreiranje specifikacija i automatsko ocenjivanje tačnosti XML-a.

XML takođe ima koncept ’’XML namespaces’’. XML namespaces pružaju način da se izbegne konflikt imenovanja. Na primer, zamislimo da postoje dve različite definicije zaposlenog u XML-u; da bi napravili razliku između njih koristi se XML namespaces. Način na koji se ovo radi je stavljanjem prefiksa na ime sa namespace prefiksom, na primer <abc:Employee>, gde je abc namespace prefiks koji sadrži definiciju tipa zaposlenog (Employee).

Postoje i druge ekstenzije koje pružaju moćne načine da se ekstraktuju i ispitaju podaci u XML poruci. Ove ekstenzije se zovu XPath i XQuery. XPath pruža način za referencu delova XML strukture, dok je XQuery moćan query jezik koji dozvoljava da query-ji budu napisani protiv XML podataka, slično SQL-u, koji je query jezik za relacione baze podataka.

Simple Object Access Protocol SOAP je važan obaveštavajući protokol koji formira osnove za skladište protokola Web usluga. SOAP poruke su

dizajnirane da budu nezavisne od transportnog protokola, ali su najčešće transmitovane preko HTTP ili HTTPS kada se koriste sa Web uslugama. SOAP poruke nisu povezana sa HTTP protokolom, međutim, mogu se koristiti u message queuing systems, slanju preko e-mail-a ili preko drugih transportnih mehanizama.


V01.2009

Page 85

SOAP standard je baziran na XML-u i definiše strukturu poruka koje se mogu prosleđivati između sistema. Poruke definisane u SOAP-u imaju omot, zaglavlje i telo kao što je prikazano na slici Slika 4.14 SOAP poruka. SOAP zaglavlje dozvoljava uključivanje elemenata sigurnosti kao što je digitalni potpis i enkripcija unutar poruke. Iako elementi sigurnosti nisu ograničeni samo na zaglavlje, dosta se koriste sa WS-S standardima za transmisiju informacija o sigurnosi zajedno sa porukom.

Slika 4.14 SOAP poruka

Postoje dva primarna moda ispisivanja poruka koje SOAP koristi – ’’dokument’’ mod i remote procedure call (RPC) mod. Dokument mod je dobar za transmisije poruka u jednom pravcu, u kome pošiljaoc piše SOAP poruku, ali ne očekuje odgovor. RPC mod se češće koristi i on predstavlja zahtev-odgovor model u kome pošiljaoc piše SOAP zahtev i onda čeka na SOAP odgovor.

WSDL i UDDI Web Services Description Language (WSDL) i Universal Description, Discovery and Integration (UDDI) standardi

dozvoljavaju potrošaču Web usluga da razume kako da nađe Web uslugu i kako da je iskoristi. Ovo uključuje sledeće:

• Otkrivanje osnovnih informacija o usluzi kao što je ime usluge

• Gde se može naći usluga, uključujući krajnje tačke mreže i korišćene protokole

• Kako pozvati uslugu (kontakt usluge)

WSDL je u suštini metapodatak u formi XML-a koji opisuje kako pozvati Web uslugu. Postoji briga o sigurnosti što se tiče čuvanja WSDL podataka, zato što ako padnu u pogrešne ruke mogu izložiti informacije o našoj mreži. WSDL metapodaci se mogu snimiti kao XML fajl, ali su često dostupni preko URL-a koji se nalazi na istom aplikacionom serveru na kom su Web usluge hosted. WSDL bi trebao da bude dostupan samo za autorizaciju korisnika usluge. Kasnije u ovom poglavlju diskutovaćemo kako su zahtevi polise sigurnosti uključeni u WSDL.

UDDI se razlikuje u tome što on definiše standard za direktorijum Web usluga. Ovo dozvoljava drugim aplikacijama ili organizacijama da otkriju WSDL za Web uslugu koja se poklapa sa njihovim potrebama. Poslovi objavljuju WSDL za njihove Web usluge u direktorijumu tako da bi bilo lako za druge da ga pronađu. UDDI direktorijumi mogu biti javno posećeni na Internet-u ili interno unutar korporacije da bi se dozvolilo da usluge budu dinamično otkrivene. Sigurnost UDDI direktorijuma mora biti održavana da bi se sprečili man-in-the-middle napadi, od strane kojih lažna Web usluga može biti objavljena umesto prave. UDDI se nadograđuje na druge standarde sigurnosti Web usluga da osigura integritet i poverenje za podatke unutar direktorijuma, što je od posebne važnosti za direktorijume koji su javno pristupačni.

XML potpis XML potpis (signature) pruža integritet i autentifikaciju XML podataka korišćenjem digitalnih potpisa i može se

primeniti na ne samo XML-u već i na bilo kojem digitalnom sadržaju. Njegova primarna korist unutar sigurnosti Web usluga je da podpiše XML poruke, da osigura integritet i dokaže indentitet potpisivača. Slika 4.15 Neformalna sintaksa XML potpisa pokazuje neformalnu prezentaciju sintakse XML potpisa. Detalji su uklonjeni da pojednostave objašnjenje strukture. Nažalost, kompletnije objašnjenje o tome kako digitalni potpisi rade je izvan okvira ovo diskusije.


V01.2009

Page 86

Slika 4.15 Neformalna sintaksa XML potpisa

Sam XML potpis je reprezentovan kao XML, kao što i slika Slika 4.15 Neformalna sintaksa XML potpisa pokazuje. Struktura sadrži sledeće elemente:

• Signature element sadrži element koji ukazuje na to da je ovo digitalni potpis.

• SignedInfo sadrži reference ka, a brojeve od podataka koji su digitalno potpisani.

• CanonicalizationMethod se odnosi na način na koji je SignedInfo element pripremljen pre izračunavanja potpisa. Razlog za ovo je da zbog različitih platformi podaci se mogu interpretirati malčice drugačije (npr. carriage returns <CR> versus carriage return/line feeds <CRLF>), što će prouzrokovati da se potpisi računaju drugačije na različitim platformama.

• SignatureMethod se odnosi na algoritam korišćen za generisanje ili ocenjivanje potpisa, npr. dsa-sha1 što se odnosi na korišćenje DSA algoritma sa SHA1 hashing funkcijom.

• Element reference je kompleksan, ali ukratko odnosi si se na podatke koji su potpisani što je ili deo istih XML podataka ili Uniform Resource Identifier (URI) koji se odnosi na eksterne podatke, kao što je dokument, Web strane ili druge digitalne sadržaje. Kao dodatak, element reference definiše transformacije koje će uticati na sadržaj pre nego što se on prosledi digest-u za računanje hash-a (preko DigestMehtod-a) Rezultujuća hash vrednost je skladištena kao DigestValue.

• SignatureValue je stvarna izračunata vrednost potpisa. Pre nego što će digitalno potpisati stvarni sadržaj, potpis se računa preko SignedInfo tako da sve reference, algoritmi i digest vrednosti su zajedno digitalno potpisane što osigurava integritet podataka koji se potpisuju.

• KeyInfo omogućava da primalac dobije ključ potreban za potvrđivanje potpisa, ako je potrebno. Ova struktura je prilično kompleksna i opisana je detaljnije pod XML enkripcijom.

• Object element sadrži XML podatke koji mogu biti pozvani u okviru SignedInfo. Takođe može sadržati Manifest element koji pruža alternativnu listu referenci, gde je proveravan integritet same liste, ali integritet stvarnih detalja neće poništiti potpis. Svrha takve liste može biti da bi sadržala popis detalja koji bi trebali da proprate manifest. Takođe definiše SignatureProperties element po kome su drugi atributi potpisa skladišteni recimo kao vreme i datum kad je potpis kreiran.


V01.2009

Page 87

Slika 4.16 Primer XML potpisa

Standard XML potpisa definiše tri tipa digitalnih potpisa, koji su enveloped, enveloping i detached. Enveloped potpis se odnosi na potpis na XML podacima, zbog čega je Signature element sadržan u telu XML-a. Enveloping potpisi sadrže XML sadržaj koji se potpisuje i ovo je gde se Object element koristi za sadržaj podataka koji su potpisani. Na kraju detached tip potpisa potpisuje sadržaj koji je eksterni XML potpisu, definisan od URI, što može biti eksterni digitalni sadržaj, ali može i da sadrži elemente unutar istih XML podataka kao što su istorodni elementi. Slika 4.16 Primer XML potpisa pruža primer detached potpisa.

Kao što je rečeno ranije, XML potpis dozvoljava svim tipovima digitalnog sadržaja da budu potpisani i postoje koristi od XML potpisa koji idu iznad okvira sigurnosti Web usluga. Bilo kako bilo, ovaj pregled XML potpisa je nameravao da pruži osnovu za razumevanje u kakvoj je on vezi sa sigurnošću Web usluga.

XML enkripcija Po dizajnu, XML je običan tekstuali format koji nema nikakvu ugrađenu sigurnost. XML enkripcija pruža podacima

poverljivost preko mehanizma za enkripciju XML sadržaja koja se oslanja na korišćenje zajedničkih simetričnih enkripcionih ključeva. Tehnike razmene standardnih ključeva baziranih na kriptografiji javnog ključa pružaju tajnost za zajednički ključ. Zajednički ključ je tipično sadržan unutar XML poruke u enkriptovanom obliku, poziva se po imenu ili URI-u, ili je izveden iz neke ključne razmene podataka. Simetrični enkripcioni ključevi se koriste za enkripciju podataka iz razloga vezanih za performanse zato što enkripcija javnog ključa može biti veoma spora u poređenju sa njima.

Slika 6.6 pokazuje neformalnu prezentaciju XML enkriptacione sintakse. Detalji su uklonjeni da bi se pojednostavilo objašnjenje strukture.


V01.2009

Page 88

Slika 4.17 Neformalna XML enkriptaciona sintaksa

Kao XML potpis, sama XML enkripcija je reprezentovana XML-om, kao što Slika 4.17 Neformalna XML enkriptaciona sintaksa pokazuje. Struktura sadrži sledeće elemente:

• EncryptedData je sadržajni element koji indentifikuje da su ovo enkriptovani podaci.

• EncryptionMethod definiše enkripcioni algoritam koji je korišćen za enkripciju podataka kao što je Triple-DES (3DES). Ovo je opcialni element i ako nije prisutan, onda primaoc mora znati koji algoritam da koristi za dekripciju podataka.

• ds:KeyInfo sadrži informacije o enkripcionom ključu koji je korišćen za enkripciju poruke. Ili je stvarni ključ ugrađen u enkriptovanu formu ili postoje neke informacije koje omogućavaju da ključ bude lociran ili izveden.

• EncryptedKey sadrži enkriptovanu formu zajedničkog ključa. Kao što je predhodno pomenuto ovaj ključ će tipično biti enkriptovan korišćenjem kriptografije javnog ključa. Može postojati više primaoca poruke, svaki sa svojim elementom enkriptovanog ključa.

• AgreementMethod je alternativan način izvođenja zajedničkog ključa korišćenjem metoda kao što je Diffie-Hellman. Pružajući ključ metodom dogovora znači da ključ ne mora predhodno biti zajednički ili ugrađen unutar elementa EncryptedKey.

• ds:KeyName pruža još jedan vid identifikacije zajedničkog enkriptacionog ključa po imenu

• ds:RetrievalMethod pruža način da se povrati enkriptacioni ključ iz URI reference, ili sadrži unutar XML-a ili eksterno od njega.

• ds:* se odnosi na činjenicu da postoje druge informacije o ključu, kao što su X.509v3 ključevi, PGP ključevi i SPKI ključevi koje se mogu uključiti.

• CipherData je element koji sadrži stvarne enkriptovane podatke, ili CypherValue kao enkriptovani podaci enkodovani kao base64 text ili korišćenje CypherReference koja se odnosi na lokaciju enkriptovanih podataka, u XML-u ili obrnuto.

• EncryptionProperties sadrži dodatne osobine kao što su datum i vreme podataka koji su enkriptovani.


V01.2009

Page 89

Slika 4.18 Primer XML enkriptovane poruke

Slika 4.18 Primer XML enkriptovane poruke pokazuje primer XML enkriptovane poruke. Enkriptovani podaci su jasno vidljivi u CypherValue elementu.

Ovaj osnovni pregled standarda XML enkripcije pomaže dobijanju osnovnog znanja kako se podaci mogu poverljivo arhivirati sa XML-om; međutim, postoji mnogo više detalja nego što se ovde može pokriti.

XML potpis i standardi XML enkripcije zajedno formiraju blokove za građenje osnovne sigurnosti na koju se oslanja ostatak WSS standarda.

4.6.3 Security Assertion Markup Language SAML je standardni framework baziran na XML-u za komunikaciju sa korisničkim identitetom, korisničkim

ovlašćenjima i korisničkim svojstvima između organizacija ili ovlašćenjima u odvojenim domenima sigurnosti. SAML je pravljen na osnovu XML potpisa i XML enkripcije da pruži integritet, poverljivost i autentifikaciju SAML izjava.

SAML dozvoljavaju osobi ili organizaciji da garantuju za identitet individue preko SAML izjave (prenosni XML autentifikacioni token). SAML izjava može biti prezentovana kao dokaz o identitetu nekoj drugoj osobi obezbeđujući vezu poverenja koja je uspostavljena između dva lica. Ovo može biti važno za SOA za koje su usluge locirane unutar posebnih kompanija ili domena sigurnosti. Ovaj koncept je u stvari osnova za sjedinjene identitete, što izdvaja organizacije od detalja autentifikacije i upravljanja identitetima unutar drugih organizacija.

SAML pokušava da reši nekoliko problema:

• Web single sign-on – po kojem se korisnik može upisati na jedan Web site a onda kasnije upisati u drugi povezan Web site koristeći credentials (SAML izjavu) koju pruža prvi site.

• Delegate identity – po kome credentials koje sadrži inicijalni Web site ili usluga, se mogu upotrebiti od te usluge da se izvrše neke akcije u ime korisnika. Primer je travel Web site, koji može proslediti korisnički identitet drugim uslugama da izvrše rezervacije aviona, hotela, kola...

• Brokered single sign-on – po kome treće lice usluga sigurnosti autentifikuje korisnika. Credentials koje pruža treće lice usluga sigurnosti se onda mogu iskoristiti za autentifikaciju na nekoliko Web site-a.

• Attribute-base Authorization – po kome se osobine korisnika stavljaju u SAML izjavu. Ove osobine se onda koriste da se naprave odluke o autorizaciji. Na primer korisnik ’’John Doe’’ ima nivo ’’direktor’’ u odeljenju za ’’ljudske resorse’’; na osnovu ovih osobina određuje se pristup sistemima za ljudske resorse.

Unutar SAML izjave biće neke informacije o identitetu korisnika, kao što je korisnička e-mail adresa, X.509 ime subjekta, Kerberos glavno ime, ili atribut kao što je identifikacioni broj zaposlenog. Za svrhe privatnosti, SAML 2.0 je predstavio koncept pseudonima (ili pseudorandom identifikatora), koji se mogu koristiti umesto drugih tipova identifikatora, pa prema tome mogu sakrivati personalne identifikacione informacije kao što je e-mail adresa. SAML pruža dva glavna načina da se potvrdi identifikacija subjekta. Jedan način se odnosi na ’’držača ključa’’, gde pošiljaoc poruke (subjekt) tipično drži ključ koji je korišćen da se digitalno podpiše poruka. Drugi metod potvrđivanja se odnosi na ’’garantovanje pošiljaoca’’, što znači da je digitalni potpis na poruci kreiran od strane trećeg lica kome se veruje.

Ovaj opis SAML-a je trebao da pruži određenu dozu razumevanja o tome gde se on nalazi unutar SOA. Leveraging-ovanjem poverljivih relacija između provajdera usluga, SAML pruža labavo uparivanje i nezavisnost sa poštovanjem korisničkog identiteta. WS-S standardi se prema SAML-u takođe odnose kao prema tokenu sigurnosti.

4.6.4 Standardi sigurnosti Web usluga Da bi razumeli kako svi protokoli sigurnosti Web usluga stoje zajedno, pogledajmo ilustraciju na slici Slika 4.19 WS-

S standard. Ovaj dijagram pokazuje kako XML potpis, XML enkripcija i SOAP formiraju temelj gomile, nad kojima se grade


V01.2009

Page 90

ostali standardi sigurnosti Web usluga. Ostali standardi, kao što su WSDL, UDDI, SAML,WS-Policy i WS-Policy Attachment su izlistani sa desne strane slike 6.8 koja ima relaciju sa standardima sigurnosti, ali oni sami nisu standardi sigurnosti.

Jasno je sa slike 6.8 da je nastavak protokola WS-Security kompleksan, što može poslužiti da obeshrabri prihvatanje ovih standarda u SOA, posebno za razvijače aplikacija čiji je posao iskomplikovan od strane ovih standarda sigurnosti. Ova kompleksnost može voditi oslanjanju na SSL i firewall polise da pruže point-to-point sigurnost za SOAP poruke. Srećom, alati su dostupni da pojednostave integraciju sigurnosti u Web uslugama i SOA.

Slika 4.19 WS-S standard

WS-Security WS-Security standard, takođe znan kao WSS: SOAP Message Security, specificira ekstenzije SOAP-a koje pružaju

integritet, poverenje i autentifikaciju poruka. WS-Security leverages XML potpis da osigura da je integritet poruke održavan i XML enkripciju da pruži poverljivost poruke. Tokeni sigurnosti imaju podršku za indetifikacione svrhe da bi pružili osiguranje da je poruka potekla od pošiljaoca identifikovanog u poruci.

Postoje tri kategorije tokena sigurnosti koji su definisani od strane WS-Security: username tokeni, binary security tokeni i XML tokeni. Svaki od tokena sigurnosti podržanih od strane WS-Security staju u jednu od ovih kategorija. Primeri tokena sigurnosti su usernames i passwords (UsernameToken), Kerberos karte (BinarySecurityToken), X.509v3 sertifikati (BinarySecurityToken) i SAML (XML Token). Zaglavlje WS-Sucurity-a je dizajnirano da bude proširljivo da bi se mogli dodati tipovi tokena sigurnosti.

Slika 4.20 SOAP poruka sa WS-S ekstenzijama pokazuje gde se pojavljuju WS-Security SOAP ekstenzije u okviru zaglavlja SOAP poruke.


V01.2009

Page 91

Slika 4.20 SOAP poruka sa WS-S ekstenzijama Primer u slici Slika 4.20 SOAP poruka sa WS-S ekstenzijama pokazuje da je struktura SOAP poruke izmenjena kad

su dodate WS-S ekstenzije. Takođe pokazuje kako tokeni sigurnosti, XML potpis i XML enkripcija stoje u okviru WS-S zaglavlja. Primaoc poruke sa WS-S ekstenzijama obrađuje ekstenzije po redu po kome se pojavljuju u zaglavlju, tako da u ovom slučaju potpis je verifikovan na telu poruke i onda je poruka dekriptovana.

1. O sledećih pet tipova tokena se diskutuje u standardu verzije 1.1:

2. Username token, koji je najosnovniji tip tokena. UsernameToken sadrži username da identifikuje pošiljaoca, a takođe može sadržati password kao običan tekst, hashed password, izvedeni password ili S/KEY password. Očigledno, korisnik password-a sastavljenog od običnog teksta je obeshrabljen.

3. X.509 token, koji je BinarySecurityToken, prepoznaje X.509v3 sertifikat koji je korišćen da se digitalno podpiše ili enkriptuje SOAP poruka kroz korišćenje XML potpisa ili XML enkripcije.

4. Kerberos token, koji je takođe BinarySecurityToken, sadrži Kerberos kartu korišćenu da pruži autentifikaciju. Ticket granting tickets (TGT) i service tickets (ST) su podržane.

5. SAML token, koji je XML token, pruža SAML izjavu kao deo zaglavlja SOAP sigurnosti.

6. Rights expression language (REL) token, koji je XML token, pruža ISO/IEC 21000 ili MPEG-21 licencu za digitalni sadržaj. Ovaj tip tokena je korišćen za povezianje licence sa pristupom, potrošnjom, razmenom ili manipulacijom digitalnog sadržaja.

WS sigurnost dozvoljava sadržavanje vremenskih pečata u okviru SOAP security zaglavlja. Vremenski pečati mogu biti zahtevani (pogledati WS-Policy i WS-SecurityPolicy) da utvrde vreme kreiranja ili isteka SOAP poruke.

Dodatno, WS-Security definiše kako dodati attachments SOAP poruci na siguran način pružanjem poverljivosti i integriteta attachments-ima. Pružena je podrška i za multipurpose Internet mail extensions (MIME) attachments i za XML attachments.

SOAP poruke i attachments mogu biti obrađeni od strane različitih posrednika duž puta do krajnjeg primaoca i WS-Security dozvoljava delovima poruka da mogu biti poslati različitim primaocima da bi stvorili pravu end-to-end sigurnost. Postoji važna razlika između point-to-point tehnologija sigurnosti kao što je SSL i end-to-end sigurnosti u kojoj postoji višestruko posrednika. Mogući scenario je da jedan posrednik možda može trebati da izvrši neke procese na poruci pre nego što je prosledi dalje; međutim, neki delovi poruke su poverljivi i namenjeni samo krajnjem primaocu. SSL neće pružiti potrebnu sigurnost u ovom scenariju.


V01.2009

Page 92

WS-Policy i WS-SecurityPolicy WS-Policy standard sam po sebi nije direktno vezan za sigurnost. Njegova svrha je da pruži kostur za opisivanje

zahteva polise na način čitljiv za mašinu. Polisa može opisivati protokole komunikacije, zahteve privatnosti, zahteve sigurnosti ili bilo koje druge tipove zahteva. WS-SecurityPolicy se nadograđuje na kostur WS-Policy da definiše polise sigurnosti za WS-Security, WS-Trust i WS-SecureConversation.

Sledeći tipovi izjava su dostupni unutar WS-SecurityPolicy:

1. Protection assertions (integriteta, poverljivosti i potrebnih elemenata), koje definišu koje delove poruke bi trebalo potpisati ili enkriptovati i koji delovi zaglavlja moraju biti prisutni.

2. Token assertions, koje specificiraju tipove tokena sigurnosti koji moraju biti sadržani (ili ne sadržani), kao što su UsernameToken, IssuedToken (token izdat od strane trećeg lica, npr. SAML), X509Token, KerberosToken, SpnegoContextToken (korišćen sa WS-Trust), SecurityContextToken (eksterni), SecureConversationToken (korišćen sa WS-SecureConversation), SamlToken, RelToken, HttpsToken (zahteva korišćenje HTTPS).

3. Security-binding assertions, koje definišu zahteve za kriptografske algoritme, vremenske pečate i raspored potpisivanja i enkripcije; bilo da potpis treba enkriptovati ili zaštititi; i bilo da potpis mora pokriti celo SOAP zaglavlje i telo.

4. WS-Security assertions, koje ukazuju koji aspekti WS-Security-a moraju biti podržani unutar poruke.

5. WS-Trust assertions, koje definišu polisu izjava vezanih za WS-Trust

Postoji srodan standard, zvan WS-PolicyAttashment, koji definiše attashment tačke unutar WSDL-a na kojima se mogu definisati polise sigurnosti. Ovo pruža mehanizam za opisivanje polisa sigurnosti povezanih sa Web uslugama zajedno sa definicijom interfejsa Web usluga.

WS-Trust WS-Trust se nadograđuje nad WS-Security i WS-Policy da definiše mehanizme za izdavanje, renorviranje i validaciju

tokena sigurnosti. WS-Trust model ima mnogo sličnosti sa Kerberos-om i postoje direktne analogije kao što su izaslaništvo i napredovanje tokena sigurnosti. Naravno WS-Trust je dizajniran da radi preko Web usluga i sa mnogo tipova tokena sigurnosti, kao što su X.509, Kerberos, XML tokeni i password digests. WS-Trust se takođe može proširiti na poverenje odnosa preko Internet-a, gde Kerberos više odgovara za pružanje poverenja unutar intranet-type scenarija. WS-Federation, o kojoj će biti reči kasnije u ovom poglavlju, se gradi nad ovim principima i dodaje mehanizme za pružanje kostura za implementaciju identiteta federacije usluga.

U WS-Trust modelu prikazanom na slici Slika 4.21 Model WS-Trust sigurnosti, Web usluga ima polisu koja definiše kojim tokenima sigurnosti je potrebno da koriste uslugu (preko WSDL-a). Da bi pristupio Web usluzi, podnosiocu zahteva je potreban važeći token sigurnosti koji Web usluga razume. Da bi došao u posed važećeg tokena sigurnosti, podnosilac zahteva može direktno zahtevati token od security token sesrvice (STS), preko RequestSecurityToken zahteva. Predpostavljajući da podnosilac zahteva adekvatno dokaže svoje tvrdnje (preko digitalnog podpisa) STS-u i odgovara STS polisi, STS će odgovoriti sa RequestSecurityTokenResponse koji sadrži novi token podpisan od strane STS-a. Ovaj novi token će biti u formatu koji Web usluga razume, iako client i Web usluga podržavaju različite autentifikacione mehanizme. Na primer, recimo da client razume samo X.509 sertifikat i da Web usluga razume samo SAML, onda STS može izdati SAML token za podnosioca zahteva koji će prezentovati Web usluzi.

WS-Trust šalje pitanja poverenja u tokene sigurnosti tako što pruža mehanizme za brokering poverljivih odnosa kroz korišćenje jednog ili više STS-a. Poverenje je ustanovljeno kroz odnose između podnosioca zahteva i STS-a, između Web usluge i STS-a i između STS-ova. Tako da Web usluga ne mora direktno da veruje podnosiocu zahteva ili STS-u koje koristi da prihvati tokene sigurnosti, dokle god postoji odnos poverenja između STS-a podnosioca zahteva i STS-a Web usluge.


V01.2009

Page 93

Slika 4.21 Model WS-Trust sigurnosti

WS-SecureConversation WS-SecureConversation standard se nadograđuje na WS-S i WS-Trust da definiše koncept konteksta sigurnosti ili

sesije između usluga. Ustanovljavanje konteksta sigurnosti ima za cilj da umanji neke od potencijalnih problema sigurnosti sa WS-S-om, kao što su message replay attacks i podrška za challenge-response protokole sigurnosti.

Postoje tri različita načina da se ustanove konteksti sigurnosti.

6. STS (pogledati WS-Trust) se koristi, gde inicijator zahteva od STS-a da kreira novi token konteksta sigurnosti

7. Inicijatoru se poverava kreiranje samog konteksta sigurnosti i slanje zajedno sa porukom

8. Novi kontekst sigurnosti je stvoren preko pregovora između učesnika, tipično koristeći WS-Trust model

Prednost WS-SecureConversation-a je da optimizira višestruke sigurne pozive Web usluga između usluga tako što izvodi autentifikacioni korak samo jednom za konverzaciju, tako što redukuje veličinu poruke korišćenjem malog indetifikatora konteksta i tako što izvodi samo brze simetrične kriptografije (koristeći zajedničke tajne ključeve). WS-SecureConversation koristi kriptografiju javnog ključa za izvođenje zajedničkih tajnih ključeva za korišćenje sa konverzacijom.

WS-Federation WS-Federation se gradi nad WS-Security, WS-Policy, WS-SecurityPolicy, WS-Trust i WS-SecureConversation da

dozvoli da identitet sigurnosti i osobine budu deljeni preko granica sigurnosti. Kao što njegovo ime sugestira, WS-Federation pruža kostur za implementiranje saveznih identiteta usluga.

WS-Federation definiše određene entitete.

I. Principal je krajnji korisnik, aplikacija, mašina ili drugi tip entiteta koji mogu poslužiti kao podnosioc zahteva.

II. STS, definisan u WS-Trust-u, izdaje i upravlja tokenima sigurnosti kao što su tokeni identiteta i tokeni kriptografije. STS se često kombinuje sa identity provider-om kada se dobija STS/IP.

III. Identity provider je specijalan tip STS-a koji izvodi autentifikaciju i polaže prava na identitete preko tokena sigurnosti.

IV. Attribute service pruža dodatne informacije o identitetu podnosioca zahteva da bi autorizovao, obradio ili personalizovao zahtev.

V. Pseudonym service dozvoljava podnosiocu zahteva (principal) da ima različite nadimke za različite usluge i opcionalno da ima promenu pseudonima po usluzi ili po log-in-u. Usluga pseudonima pruža identity mapping services i može opcionalno pružiti privatnost za podnosioca zahteva, korišćenjem različitih identiteta preko provajdera.

VI. Validation service je specijalan tip STS-a koji koristi WS-Trust mehanizme da potvrdi dostupne tokene i utvrdi nivo poverenja u tim dostupnim tokenima.

VII. Trust domain ili realm je nezavisno administrativan prostor sigurnosti, kao što je kompanija ili organizacija. Prolaženje od jednog domena poverenja do drugog uključuje prelaženje granice poverenja.


V01.2009

Page 94

Ove usluge se mogu urediti na drugačije načine da bi odgovarali različitim zahtevima za poverenjem, od jednostavnih do prilično kompleksnih scenarija poverenja. Primer na slici 11 ilustruje prilično kompleksan scenario u kome podnosilac zahteva prvo zahteva token od STS/IP-a kome veruje. (1) Token sigurnosti je onda prezentovan STS-u resorsa radi zahteva da token dobije pristup resorsu. (2) Predpostavljajući da je token podnosioca zahteva ispravan, STS resorsa će izdati novi token, koji je onda prezentovan Web resorsu da zahteva pristup. (3) Resors Web usluge u nekom trenutku treba da izvrši posao na ime principal-a, tako da postavi upit za još jedan STS/IP u odvojenom domenu sigurnosti da bi došao u posed delegated tokena sigurnosti. (4) Predpostavljajući da Web usluga ima odgovarajući dokaz kome je dozvoljeno da izvrši delegation, STS/IP će izdati token sigurnosti. (5) Ovaj delegated token sigurnosti je onda prezentovan resorsu na ime principal-a. Lanac poverenja između podnosioca zahteva i resorsa u domenu poverenja C se može videti na slici 6.11.

WS-Federation predstavlja modele odnosa za direktno poverenje, direktno brokered poverenje, indirektno brokered poverenje, delegated poverenje i federaciono poverenje. Druge usluge mogu biti dodate na sliku kao što su usluge atributa i pseudonima za autorizacije bazirane na atributu, autorizacije bazirane na ulozi, članstvo i personalizaciju. Usluge pseudonima skladište alternativne informacije o identitetu, koje mogu biti korišćene u scenariju cross-trust domena da podrže nadimke i mapiranje identiteta.

WS-Federation takođe opisuje način za učesnike da promene metapodatke kao što su sposobnosti, potrebe sigurnosti i karakteristike Web usluga koje formiraju federaciju. Ova razmena metapodataka se postiže korišćenjem drugog standarda zvanog WS-MetadataExchange, koji se prvenstveno gradi nad WSDL i WS-Policy.

Slika 4.22 Primer WS-Federation-a

WS-Authorization i WS-Privacy (predloženi standardi) Kako ovi standardi još nisu izdati, ovde su pomenuti samo zbog kompletiranja. WS-Privacy je predložen standardni

jezik za opisivanje polisa privatnosti za korišćenje sa Web uslugama. Standard je nameravan za korišćenje od strane organizacija da iznesu svoju polisu privatnosti i da označe svoj pristanak na te polise. WS-Autorization je predložen standard za kako opisati polise autorizacije za Web usluge koristeći fleksibilan autorizacioni jezik. Standard će objasniti kako autorizacione tvrdnje mogu biti specifirane u tokenu sigurnosti i označene u krajnjoj tački.

WS-I Basic Security Profile 1.0 Pošto postoji veliki broj WS-* standarda sigurnosti, vendori ih implementiraju u različitim vremenima i nisu sve

opcije opšte od jednog vendorovog sistema do drugog. WS-I Basic Security Profile 1.0 je nameravan da pruži osnovnu liniju za WS-Security internu operativnost između različitih vendorovih produkata. Ideja je da ako produkti potvrde Basic Security Profile 1.0 , onda bi trebali biti interoperativni bar do nekog nivoa. Ovo može biti važno pri implementaciji SOA-e sa produktima od različitih vendora, kao što su Sun’s Java J2EE, BEA Weblogic i Microsoft’s .NET Platform.


V01.2009

Page 95

Basic Security Profile 1.0 podržava dobar broj ekstenzija sigurnosti, uključujući Kerberos, SAML, X.509 i username tokene i podršku za SSL transport-layer security (HTTPS).

4.6.5 Preporuke implementacije sigurnosnih politika pri dizajnu aplikacija Sada kada smo pokrili sve Web Service Security standarde, možemo primeniti ovo znanje na problem obezbeđivanja

SOA baziranom na Web usluge.

Važno je primetiti da bi tradicionalni principi sigurnosti trebali da formiraju osnovu sigurne SOA. Okruženjem u kome sistemi rade trebalo bi odgovarajuće upravljati da bi se osiguralo da su polise sigurnosti organizacije zadovoljene i da su odgovarajući kontrolni zahtevi stavljeni nad organizacijom. Ovo uključuje pažnju na sigurnost mreže, sigurnost operativnog sistema, sigurnost aplikacija (uključujući infrastrukturu Web usluga) i fizičku sigurnost. Procene rizika sigurnosti, analiziranje pretnji, skeniranje za ranljivostima i tehnike testiranja penetracije bi trebale biti korišćene da potvrde sigurnost SOA usluga, platformi i za njih vezanih sistema.

Da bi se izvela celokupna procena sigurnosti, trebali bi se postaviti sledeći tipovi pitanja:

• Kako krajnja SOA izgleda?

• Ko su nameravani potrošači usluga?

• Kako su usluge otkrivene od potrošača? Da li je WSDL ili UDDI korišćen?

• Koje se interakcije pojavljuju između potrošača i usluga i između usluga?

• Da li su neki od usluga ili potrošača na nepoverljivim mrežama?

• Koji tipovi podataka se prenose između potrošača i usluga u raznim tačkama?

• Da li je integritet ili poverenje podataka potrebno u bilo kom trenutku unutar SOA?

• Da li podaci teku kroz višestruko posrednika?

• Ima li potrebe za pružanjem end-to-end sigurnosti za određene tipove podataka?

• Koji su zahtevi za autentifikaciju i autorizaciju svake usluge?

• Da li je autorizacija bazirana na ulogama ili atributima?

• Da li je privatnost podataka briga?

• Koje tehnologije sigurnosti, kao što su X.509, Kerberos ili SAML su dostupne?

• Da li su višestruki domeni sigurnosti obuhvaćeni? Postoji li potreba za cross-domain odnosima poverenja?

• Postoje li različite tehnologije Web usluga, kao što su J2EE, Weblogic ili .NET, i da li pri korišćenju mogu prouzrokovati probleme sa podrškom ili interoperativnošću protokola? Ako je tako, da li je podržan WS-I Basic Security Profile 1.0?

• Analiza pretnje – koje potencijalne pretnje postoje za infrastrukturu, kao što su zlonamerni napadi, unutrašnje pretnje, razotkrivanje informacija, message replay napadi ili denial-of-service (DoS)?

Sledeće nabrajanje zbraja tipove pretnji koje se primenjuju na SOA i mehanizme za umanjivanje tih pretnji:

• Information disclosure (confidentiality) – korišćenje XML enkripcije unutar WS-Security može pružiti poverljivost informacija. Poverljivošću end-to-end poruka se takođe može upravljati XML enkripcijom.

• Message tampering - Message tampering se može koristiti za uklanjanje XML-a, dodavanje XML-a ili na neki drugi način promeniti podatke ili izazvati neko nenameravano ponašanje unutar aplikacije. XML podpisi se mogu koristiti da osiguraju integritet poruka.

• Message injection - Message injection se može iskoristiti da izazove neko nenameravano ponašanje unutar aplikacije. Autentifikacioni mehanizmi i ulazna provera valjanosti unutar usluge mogu pomoći da se smanji ovaj problem.

• Message replay – WS-Secure Conversation pruža mehanizme da spreči ovu vrstu napada, ali i obratno, identifikatori poruka ili vremenski pečati se mogu koristiti da spreče message replay.

• Authentication – autentifikacija je pružena od strane XML potpisa i tokena sigurnosti kao što su Kerberos, X.509 sertifikati i SAML ili čak username tokeni. Ove metode su podržane od WS-Security i WS-Trust.


V01.2009

Page 96

• Authorization – autorizacija može biti bazirana na ulozi ili atributu. Platforme za Web usluge će tipično pružiti neki oblik auterizacione sposobnosti, ali za naprednije autorizacione potrebe, aplikacija će morati uključivati eksplicitne autorizacione provere.

• Service availability – nepogode, bilo prirodne ili od strane čoveka, trebaju se planirati tako što će se osigurati da je na mestu adekvatna strategija za oporavak od nepogode. Drugi zlonamerni napadi kao što je DoS mogu uticati na mrežu, operativan sistem ili aplikaciju. No međutim, upuštanje u borbu sa DoS napadima je izvan okvira ovog poglavlja.

• Token substitution – pokušaji da se zameni jedan token sigurnosti sa drugim mogu biti sprečeni tako što će se osigurati da digitalni podpisi pruže integritet preko svih kritičnih delova sigurnosti poruke, uključujući tokene sigurnosti.

Kada se procena rizika završi i razumeju se zahtevi za sigurnost, odluke bi trebale da se donesu o tome kako osigurati SOA okruženje. Rizici su normalno rangirani u terminima udara i verovatnoće i treba ih postaviti po prioritetu – na primer u visoko-rizične, srednje-rizične i nisko-rizične kategorije. Mere sigurnosti se onda mogu izabrati da umanje rizike i udovolje zahtevima sigurnosti, baziranim na cost-benefit analizama.

Generalne principe sigurnosti bi trebalo pratiti prilikom izbora mera sigurnosti, kao što su:

Osiguravanje poverljivosti, integriteta i dostupnosti podataka i usluga

Duboka odbrana

Princip najmanje privilegije

Minimizovanje napadnute površine

Praktikovanje jednostavnosti više nego kompleksnosti

Na bilo kom nivou mreže, firewall polise se mogu primeniti da ograniče pristup Web uslugama, zato što se SOAP poruke transmituju preko HTTP-a, obično na Transmission Control Protocol (TCP) port 80, ili preko HTTPS-a na TPC port 443. Internet-facing serveri bi trebali da imaju pristup zabranjen samo na port-u koji sluša usluga. Firewall polise mogu formirati prve linije odbrane tako što će redukovati dostupnu površinu napada. Tehnike drugih standarda, uključujući DMZ arhitekturu, zone sigurnosti i detekciju/prevenciju upada mogu redukovati rizik na nivou mreže i pružiti duboku odbranu.

Na nivou transporta, Web usluge su obično obezbeđene korišćenjem SSL-a, preko HTTPS protokola, a i polise mogu biti primenjene preko WSDL-a da osiguraju da su Web usluge obezbeđene SSL-om. Korišćenje SSL-a bi definitivno trebalo biti razmotreno, naročito zato što je dobro razumljiv protokol, mada je važno razumeti da SSL pruža samo point-to-point enkripciju i da druge tehnike trebaju biti primenjene ako sigurnost SOAP poruka treba održavati izvan SSL sesija.

Na nivou poruke, XML je po prirodi standard baziran na tekstu, zato poverljivost i integritet podataka nisu ugrađeni. SOAP poruke i dodaci mogu biti obrađeni od strane različitih posrednika duž puta do krajnjeg primaoca i WS-Security dozvoljava delovima poruka da budu poslati različitim primaocima. Ovo je važna razlika između point-to-point tehnologija sigurnosti, kao što su SSL i end-to-end sigurnosti, koju podržava WS-Security. XML enkripcija može pružiti end-to-end poverljivost podataka preko kriptografije javnog ključa i kriptografije zajedničkog simetričnog ključa, gde XML potpis može odgovarati integritetu podataka i autentifikacionim potrebama poruke.

Druga pitanja postoje kad se radi sa poverljivim odnosima i cross-domain autentifikacijom. Standardi WS-Trust i WS-Federation-a pružaju tehničku osnovu za ustanovljavanje poverenja za SOA. Organizacione polise osiguranja i pravni zahtevi bi trebali definisati potrebe sigurnosti koje trebaju vršiti interakciju sa mušterijama i poslovnim partnerima. Potrebe sigurnosti se mogu iskoristiti kao osnova za utvrđivanje mehanizma sigurnosti koji trebaju biti iskorišćeni da pruže odgovarajuće nivoe poverenja, kao što je snaga enkripcije ili metod autentifikacije (X.509 digitalni sertifikati, SAML, Kerberos, itd.). međutim, poverenje između organizacija ide iznad tehničkih implementiranih detalja i treba biti obavezano ugovorom i poslovnom diskusijom.

4.6.6 Zaključak WS-S porodica pruža bitan set standarda za osiguravanje SOA-e; međutim, broj i kompleksnost standarda su

definitivno problem. Ova kompleksnost može poslužiti da obeshrabri prihvatanje ovih standarda u SOA, naročito za razvijače aplikacija, čiji je posao zakomplikovan potrebama sigurnosti. Ovi standardi takođe evoluiraju i novi standardi sigurnosti se razvijaju, zato možemo očekivati da pejzaž SOA sigurnosti evoluira tokom vremena.

Srećom vendori pružaju nove alate da pojednostave integraciju WS-Security standarda u Web usluge. Ovi alati mogu pomoći sakrivanjem mnogih detalja, koji su na nižem nivou, od praktikanta i arhitekata sigurnosti. Očekujmo da ovi alati evoluiraju tokom vremena kako SOA i Web usluge postaju zreliji. U ovo vreme, međutim, i dalje nije lako integrisati WS-Security standarde u Web usluge.


V01.2009

Page 97

Za onog koji praktikuje sigurnost, principi sigurnosti standarda mogu biti poređani po nivoima da asistiraju u vođenju arhitekata i razvijača pri odabiru odgovarajućih mehanizama za osiguravanje SOA-e.


V01.2009

Page 98

5. Tehnike zaštite raačunarskih mreža 5.1. problematika zaštita računarskih mreža

Sve korporacije imaju potrebu da zaštite svoje poslovne transakcije, podatke klijenata i intelektualno vlasništvo. Na minimumu, gubljenje ili ugrožavanje podataka mogu stvoriti noćne more od javnih odnosa ili ozbiljno povrediti reputaciju tržišta. Na duže staze, može imati uticaje na odnose klijenata ili stvoriti ozbiljnu finansijsku štetu od prevara, krađe informacija ili javnog razotkrivanja intelektualnog vlasništva. Ovaj problem je predstavio informacionu tehnologiju sa tehnološkim izazovom zato što idealno rešenje zaštite mrežnih podataka ne bi trebalo zahtevati promene na mrežnoj infrastrukturi, ne bi trebalo imati uticaja na performanse mreže, moralo bi raditi preko svake topologije mreže i moralo bi osiguravati sve vrste mrežnog saobraćaja. Izazov sa kojim se suočavaju profesionalci koji se bave sigurnošću informacija je da osiguraju pokretne podatke kao što nikad pre nije bilo moguće. Očigledno je da je enkripcija rešenje po pitanju poverljivosti i integriteta podataka prilikom njihovog tranzita kroz linije nad kojima nemamo kontrolu; međutim, njihova ograničenja su sprečila njihovo razvijanje, naročito na široko-opsežnim mrežama. Standardi su normalno predstavnjeni kad je interoperativnost između različitih rešenja vendora postala stvarnost i mnogo dobrih je iskorišćeno, na primer, Internet Protocol security (IPSec) standardna osnova. Iako IPSec donosi deo rešenja, takođe je predstavio i svoja ograničenja i nepotrebno preklapanje na postojeću infrastrukturu mreže, čineći je još težom za upravljanje, održavanje i obavljanje operacija.

5.2. Zaštita savremenih visokopropusnih računarskih mreža

5.2.1 Performanse Ne tako davno infrastrukture mrežnih podataka su korišćene samo za masivan transfer podataka preko sporih linija

raznog, često nepouzdanog, kvaliteta. Podaci koji su prenošeni preko tih mrežnih infrastruktura su bili manje važni, pa čak i ako ukradeni, modifikovani ili izgubljeni, uvek su postojale višestruke kopije i formulari koji bi ih zamenili po potrebi. U današnje vreme moderna visoko-brzinska mrežna infrastruktura prenosi najkritičnije delove podataka kao i višestruke aplikacije od velikog značaja za kompanije koje se uzdaju u njih za svoju egzistenciju. Dodavanjem enkripcije na komunikacione puteve, ukoliko nemaju podršku specijalnog hardware-a, tipično se smanjuje ukupna komunikaciona brzina i, prema tome, vrši uticaj na korisnost visokobrzinskih komunikacionih puteva.

5.2.2 Redundantnost High-speed, high-performance mreže moraju raditi sve vreme, bez obzira šta se dešava sa individualnim

komunikacionim komponentama. Pa prema tome, moderan dizajn mreža uključuje višestruke redundantne uređaje kao i višestruke dostupne puteve ugrađene u samu mrežu. Redundantnost ugrađena u mrežu čuva dostupnost komunikacionih puteva između višestrukih tačaka u mreži; međutim, često izaziva poteškoće za mehanizme sigurnosti.

5.2.3 Load balancing Višestruki redundantni putevi nije neophodno da rade u master-slave ili active-standby režimu, ali mogu biti aktivni i

korišćeni istovremeno da rade load balancing i dele teret saobraćaja kroz nekoliko veza. Ovo je preferirani način za efikasne mreže da koriste nekoliko dostupnih veza, ali takođe ima, nažalost, neke implikacije sigurnosti. Odnosi sigurnosti su tipično fiksirani između peers i u nevolji su kad izgube odnose nekog peer-a koji moraju biti dinamično ustanovljeni kada mrežni saobraćaj izabere neki drugi put do iste destinacije.

5.2.4 Multiemitovanje Bilo koja vrsta grupne komunikacije – multiemitovanje je samo jedna od njih – zahteva grupnu sigurnost odnosa

članova kao i grupnu kontrolu članova ako neki od komunikacionih peers-a napusti ili se pridruži grupi. To čini ekriptovanu grupnu komunikaciju ekstremno teškom, sa visokim preklapanjem peer-to-peer odnosa koji rastu eksponencijalno sa brojem peers-a koji komuniciraju. Poznata je matematička činjenica da je za neki ’’n’’ broj peers-a potrebno imati ’’n x (n-1)’’ peer-to-peer odnosa i to puta 2 ako svaki pravac mora biti osiguran posebno.

5.2.5 Više-protokolsko menjanje oznaka Multi-Protocol Label Switching (MPLC) širokih površina mreža pruža najveći deo daleko-dostižne konektovanosti

danas, ma koliko god da menjali višestruke starije tehnologije kao što su Frame Relay, X.25 ili iznajmljene linije. MPLS pruža skoro istu funkcionalnost u poređenju sa svojim predhodnicima preko kreiranja odvojenih, izolovanih komunikacionih puteva baziranih na različitim oznakama. Izolovanost saobraćaja, međutim, ne pruža ni poverljivost ni autentifikaciju podataka koji


V01.2009

Page 99

putuju preko MPLS mreže i čini podatke otvorenim za višestruke rizike dok putuju preko deljene infrastrukture, kao što je moguće curenje podataka zbog grešaka u konfiguraciji ili protivzakonitog korišćenja.

5.3. Mogućnosti enkripcije Bilo je očigledno kroz istoriju komunikacionih protokola da je zaštita podataka dok putuju preko neosiguranih kanala

za podatke mogla biti ostvarena enkripcijom. Međutim, enkripcija je dokazala da može biti težak zadatak jer takođe zahteva da se mnogo drugih elemanata tačno odradi, da ne bi imali uticaja na moderne mreže komunikacionih podataka. Kao što je ranije napomenuto, enkripcija ima uticaj na performanse, redundantnost i load balancing modernih mreža današnjice i takođe potrebe bilo kog tipa grupne komunikacije čini korišćenje enkripcije problematinim. Dalje, postoje nekoliko opcija gde implementirati enkripciju: na link level, network level, ili application level.

5.3.1 Link level enkripcija Link level ekripcija je jedan od najranije dostupnih tipova i nema zahteve za standardizaciju jer je uvek bio uređaj

istog vendora na oba kraja linije. Key menagement protocols su često privatni i ugrađeni kao deo rešenja. Zbog toga cena takvog uređaja je bila velika i kad jedan uređaj ne bi uspeo da obavi point-to-point topologiju oba bi morala da se zamene. Problemi link-level enkripcije su došli sa novim opcijama mrežne konektivnosti medija, kao što su mesh topologije kao i mnogi različiti putevi kroz istu mediju. Ovo je dovelo do opcije razvijanja enkripcije na drugim nivoima, kao što su application ili network level.

5.3.2 Application level enkripcija Application level enkripcija je, sa tačke gledišta sigurnosti, najviši nivo – tako što aplikacija koja proizvodi podatke

ima najbolji pogled na to kako ih zaštititi. Bilo bi divno kad bi svaka aplikacija imala ugrađenu mogućnost enkriptovanja; međutim, kako sigurnost u prošlosti često nije bila tema, mnoge legalne aplikacije su ostale bez nje i nemaju opciju za njeno uključivanje. Novije aplikacije većinom imaju opciju da zaštite podatke enkripcijom; međutim, svaka od njih ima svoj različit način kako to da uradi, što čini scalability kao i intra-application transfer zaštite podataka nemogućim ili nonscalable.

5.3.3 Network level enkripcija Zahvaljujući ograničenjima i manama drugih prethodno pomenutih opcija i nivoa za enkriptovanje podataka, mrežni

nivo je završio kao najčešće korišćen izbor. Network-level enkripcija pruža jednaku zaštitu za nasledne aplikacije kao i za novije aplikacije prenoseći iste mrežne protokole i ne zahteva nikakve druge promene aplikacija. Kako je Internet Protocol (IP) postao najdominantniji mrežni komunikacioni protokol danas, suzićemo našu diskusiju o enkriptacionim osobinama na unutar IP sa njegovom osnovom za protokole sigurnosti, IPSec. IPSec protokol je standardizovan kasnih 1990-tih i kroz brojne interoperativne implementacije, oprema bazirana na IPSec-u je postala dostupnija za kupovinu od uređaja za link-level enkripciju, ali kao i obično i ona ima svoje prednosti i ograničenja, na koja ćemo se fokusirati u daljem tekstu.

5.4. Ograničenja IPSec enkripcije IPSec set request for comment (RFC) standarda definišu autentifikaciju kao i enkripciju IP paketa. Takođe definišu

različite modove operacije kao i Internet key exghange (IKE) automatizovan key-derivation protokol koji pomaže razmeni ključeva baziran na predefinisanom vremenskom intervalu ili količini transferovanih podataka. Zajedno, IKE i IPSec su dobili široku implementaciju na ruterima, layer-three prekidačima i edge devices kao što su firewalls, kao i end nodes koji rade na različitim operativnim sistemima. Sa širokom implementacijom, takođe, IPSec i IKE su predstavili nova ograničenja. IPSec i IKE su po definiciji peer-to-peer protokoli koji utiču na mrežnu komunikaciju ako postoje redundantni putevi ili ako je load balancing uključen. Peer-to-peer poverljivi odnosi takođe čine enkriptovanu grupnu komunikaciju veoma teškom. Ovo je ilustrovano na slici Slika 5.1 Redundantna arhitektura mreže i slici Slika 5.2 Grupna (multicast ili broadcast) arhitektura mreže. Zadnje ali ne i najmanje, ako ne implementovani u hardware-u, određeni ekriptacioni procesi takođe imaju uticaja na performanse komunikacija na bilo kojoj higher-speed mrežnoj konekciji.

Slika 5.1 Redundantna arhitektura mreže


V01.2009

Page 100

Slika 5.2 Grupna (multicast ili broadcast) arhitektura mreže

Slika 5.3 IPSec/IKE opšta arhitektura

5.5. Upravljanja distribucijom ključeva u mreži IPSec i IKE zajedno predstavljaju tri glavne funkcije najčešće implementirane zajedno na istoj, jedinstvenoj radnoj

platformi. Ove tri funkcije su definicija polise sigurnosti, razmena ključa i enkripcija. Najopštija implementacija za sve tri funkcije kao jedna IPSec/IKE arhitektura je ilustrovana na slici 3. Implementacija sve tri glavne enkriptacione komponente na istoj fizičkoj platformi izgleda kao očigledan izbor; međutim, donosi sa sobom i svoja ograničenja peer-to-peer odnosa i, zbog toga, utiče na moderne mrežne komunikacije. Da bi se postigao otporan i redundantan dizajn mreže, arhitektura enkriptovane sigurnosti bi trebala imati svoje komponente dizajnirane na isti način. Tri glavne komponente u suštini predstavljaju tri individualne uloge: masovnu enkripciju, koja se može uraditi na policy enforcement point (PEP); key management, za koju može da se pobrine ključna tačka autoriteta; i polise sigurnosti, koje se mogu odraditi na serveru za upravljanje i polise. Ovaj distributivni model predstavljen sa tri individualna sloja, upravljanje, distribucija i enkripcija je ilustrovan na slici Slika 5.4 Distributed policy i key management arhitektur. Svaka od glavnih funkcionalnih komponenti može prema tome izvršiti svoj posao pošto je implementovana na individualne platforme, pa zbog toga takođe može donositi dodatne benificije kao što je scalability. Svaki od slojeva u tro-rednom modelu može biti repliciran do potrebnog service-scale nivoa i podržati rast kao što je potrebno za široko-opsežne mrežne dizajne. Tro-redna arhitektura sigurnosti je ilustrovana na slici Slika 5.5 Three-tier encryption security arhitektura. Sloj distribucije ključa i sloj distribucije polise moraju biti dizajnirani sa redundancy i failover mehanizmima kao i ujedinjenim modulima hardware-ske sigurnosti za generisanje ključa. Skladište ključa mora biti ’’hack-proof’’ sistem bez backdoor-a i bez mogućih traffic-probing ranljivosti. Dodatni problem za rešavanje je sigurnost saobraćaja između slojeva.


V01.2009

Page 101

Slika 5.4 Distributed policy i key management arhitektura

Slika 5.5 Three-tier encryption security arhitektura

To se može rešiti upotrebom ili IKE ili drugih sigurnih ali manje težih protokola, kao što je Transport Layer Security protokol. Skaliranje u takvom distributivnom modelu je po dizajnu ugrađeno od početka. Tro-redna arhitektura ne dozvoljava scalability polisa sigurnosti nikada pre mogućeg korišćenja IPSec-a. Grupisane mreže i jedinice mrežnih uređaja zajedno preko definicija grupne polise dramatično pojednostavljuju generisanje polisa. Prema tome, po slojevima postavljena arhitektura enkriptacione sigurnosti može služiti više hiljada end-node PEP-sa u mreži i, takođe, preko otvorenih aplikacija za programiranje interfejsa može pružiti pristup stotinama hiljada viševendorskih uređaja, kao što su desktops, notebooks, cell phones, personal digital assistants i printers.

Dodatni element koji pomaže da se razbije point-to-point odnos je da je PEPs odgovoran za najveći deo enkripcije koja radi IPSec održavanje orginalne IP adrese zaglavlja, kao što je ilustrovano na slici Slika 5.6 Čuvanje IPSec tunnel-mode zaglavlja.


V01.2009

Page 102

Slika 5.6 Čuvanje IPSec tunnel-mode zaglavlja

Sa sačuvanim orginalnim IP zaglavljem, ne postoji dodatna potreba za kreiranjem bilo kojih point-to-point odnosa i, još važnije, nema potrebe za kreiranjem bilo kakvih dodatnih mreža na već postojeću infrastrukturu. To pojednostavljuje enkriptacionu funkciju na postojećim modernim mrežama do mogućeg maksimuma i kao takva samo dodaje fleksibilnost omogućavanju redundantnosti, load balancing-a, kao i grupne broadcast ili multicast komunikacije.

ukratko Izazov pred profesionalcem koji se bavi sigurnošću informacija je da osigura podatke u pokretu kao nikad ranije.

Enkripcija je očigledan izbor za rešenje ali ono mora raditi preko mrežne topologije i mora činiti sigurnim bilo kakve tipove saobraćaja. Poželjno je da se sve to uradi bez potrebe za menjanjem infrastrukture mreže ili vršenja uticaja na mrežne performanse. IPSec protokol pruža deo rešenja ali je takođe i deo problema, sa svojom point-to-point prirodom kao i sa modelom dopune mreže. Arhitektura po slojevima postavljene enkriptacione sigurnosti donosi rešenje potrebama za modernu zaštitu podataka kroz separaciju glavnih uloga i funkcija enkripcije u tri individualna sloja. Takva tro-redna arhitektura ekriptacione sigurnosti donosi naslednu scalability i više ne zahteva mrežne dodatke za generaciju i distribuciju polisa i enkriptacionih ključeva. Pruža zaštitu podataka ali ne zahteva nikakve promene na mrežnoj infrastrukturi, ne vrši uticaj na mrežne performanse i radi preko topologije mreže. Koncept je taj koji bi trebalo, kad dobije široku implementaciju, da reši problem zaštite podataka preko enkripcije u široko-opsežnom razvijanju mreža.


V01.2009

Page 103

6. Zaključak U ovoj skripti nalaze se odabrane tehnike i standardi zaštite poverljivosti informacija.

Neka poglavlja su obavezna literatura za polaganje prednemeta „Bezbednost informacionih sistema“ na smeru Informatika, visoke tehničke škole u Kragujevcu, dok su ostala poglavlja prikazana kao dodatno štivo i praktični saveti profesionalcima u praktičnom radu.

Prikaazani su, dosta detaljno, metode, standardi i odabrane tehnike kojima možemo zaštititi naš informacioni sistem. Naglasili smo i razmotrili moguća rešenja za rizike koji stvaraju razne vrste pretnji koje mogu kompromitovati informacioni sistem. Saznali smo da pored raznih vrsta software-skih zaštita postoje i fizičke mere sigurnosti i provera indentiteta i autentifikacije korisnika odnosno zaposlenih.

Za sve vrste zaštita postoje određeni rizici i pretnje po njih, a na nama je da u odnosu na naš konkretan poslovni sistem, procenimo važnost podataka i nivoa autorizacije i na osnovu toga savesno donesemo odluke vezane za izbor odgovarajuće tehnike zaštite datog informacionog sistema.


V01.2009

Page 104

7. Literatura 1. Informatuin Security MAnagemant Handbook, H. Tipton, M. Krouse, CISP, CRC Press, 2008 New York, USA


V01.2009

Page 105


V01.2009

Page 106

8. Dodatak 8.1. Slike

Slika 1.1 Model integralne informacione sigurnosti -CIA ..............................................................................................8 Slika 2.1 P-D-C-A ciklusu (Demingov krug)................................................................................................................12 Slika 2.2 Mapa zemalja u kojima su primenjeni ISO standardi ....................................................................................15 Slika 2.3 Razvoj standarda............................................................................................................................................16 Slika 3.1 Simetrična kriptografija .................................................................................................................................21 Slika 3.2 Inverzni poredak od L16 i R16 .........................................................................................................................23 Slika 3.3 S-kutija...........................................................................................................................................................23 Slika 3.4 Electronic Codebook – ECB mod..................................................................................................................27 Slika 3.5 Cipher Block Chaining - CBC mod ...............................................................................................................27 Slika 3.6 Cipher Feedback - CFB mod .........................................................................................................................28 Slika 3.7 OFB mod .......................................................................................................................................................28 Slika 3.8 Counter - CTR mod .......................................................................................................................................29 Slika 3.9 ........................................................................................................................................................................30 Slika 3.10 ......................................................................................................................................................................30 Slika 3.11 ......................................................................................................................................................................31 Slika 3.12 ......................................................................................................................................................................31 Slika 3.13 ......................................................................................................................................................................32 Slika 3.14 Twofish algoritam........................................................................................................................................33 Slika 3.15 ......................................................................................................................................................................35 Slika 3.16 ......................................................................................................................................................................35 Slika 3.17 Šifrovanje dokumenta ..................................................................................................................................40 Slika 3.18 Dešifrovanje dokumenta ..............................................................................................................................41 Slika 3.19 Početni dijagram toka hibridne enkripcije ...................................................................................................42 Slika 3.20 Dijagram toka sa završenim hibridnim šifriranjem......................................................................................43 Slika 3.21 RSA šifrovanje.............................................................................................................................................44 Slika 3.22 Dijagram AES algoritma..............................................................................................................................46 Slika 3.23 AES Proces Enkripcije.................................................................................................................................47 Slika 3.24 Kreiranje digitalnog potpisa (primer za MD5 HASH alogoritam i RSA algoritam)....................................51 Slika 3.25 Verifikacija digitalnog potpisa.....................................................................................................................52 Slika 3.26 Struktura digitalnog sertifikata.....................................................................................................................53 Slika 4.1 Vrste i izgled tokena ......................................................................................................................................56 Slika 4.2 Cain & Abel password-cracking tool.............................................................................................................57 Slika 4.3 Man-in-the-middle napad...............................................................................................................................58 Slika 4.4 Reputation defenses .......................................................................................................................................59 Slika 4.5 Reputation defenses .......................................................................................................................................60 Slika 4.6 Primer strukture domena................................................................................................................................67


V01.2009

Page 107

Slika 4.7 Gnezdeće grupe.............................................................................................................................................68 Slika 4.8 Kompletan dijagram implementacije odgovornosti .......................................................................................69 Slika 4.9 Optički turnstile sa barijerom.........................................................................................................................80 Slika 4.10 Rotirajuća vrata............................................................................................................................................80 Slika 4.11 Tradicionalni turnstile ..................................................................................................................................81 Slika 4.12 Primer pojednostavljene SOA......................................................................................................................83 Slika 4.13 Jednostavan XML primer ............................................................................................................................84 Slika 4.14 SOAP poruka ...............................................................................................................................................85 Slika 4.15 Neformalna sintaksa XML potpisa ..............................................................................................................86 Slika 4.16 Primer XML potpisa ....................................................................................................................................87 Slika 4.17 Neformalna XML enkriptaciona sintaksa ....................................................................................................88 Slika 4.18 Primer XML enkriptovane poruke ...............................................................................................................89 Slika 4.19 WS-S standard .............................................................................................................................................90 Slika 4.20 SOAP poruka sa WS-S ekstenzijama...........................................................................................................91 Slika 4.21 Model WS-Trust sigurnosti..........................................................................................................................93 Slika 4.22 Primer WS-Federation-a ..............................................................................................................................94 Slika 5.1 Redundantna arhitektura mreže .....................................................................................................................99 Slika 5.2 Grupna (multicast ili broadcast) arhitektura mreže......................................................................................100 Slika 5.3 IPSec/IKE opšta arhitektura.........................................................................................................................100 Slika 5.4 Distributed policy i key management arhitektura ........................................................................................101 Slika 5.5 Three-tier encryption security arhitektura....................................................................................................101 Slika 5.6 Čuvanje IPSec tunnel-mode zaglavlja .........................................................................................................102

8.2. Tabele Tabela 1.1 Kategorije informacionih resursa koje je neophodno zaštiti .........................................................................9 Tabela 2.1 Istorijat standarda ........................................................................................................................................11 Tabela 3.1 Postupak zamena bitova ..............................................................................................................................48

8.3. Grafovi Graf 1.1 Uzroci i tipovi kompjuterskog kriminala ..........................................................................................................9

Documents

BEZBEDNOST INFORMACIONIH SISTEMA