FAKULTET ZA POSLOVNU INFORMATIKU

Prof. dr Milan Milosavljavić

mr. Gojko Grubor, dipl. inţ. el.

OSNOVI BEZBEDNOSTI I
ZAŠTITE INFORMACIONIH
SISTEMA
- Razvoj i upravljanje programom zaštite -

Drugo izdanje

Beograd, 2006. godine

Autori:
Prof. dr Milan Milosavljavić
mr. Gojko Grubor, dipl. inţ. el.
Recenzenti:
Prof. dr ...

Izdavač:
UNIVERZITET SINGIDUNUM
FAKULTET ZA POSLOVNU INFORMATIKU

Za izdavača:
Prof. dr Milovan Stanišić

Dizajn korica:
Aleksandar Mihajlović
Goran Latinović

Godina izdanja:
2006.

Tiraž:
000 primeraka

Štampa:
ĈUGURA-print
Beograd

ISBN:
 SADRŢAJ:

I GLAVA
METODOLOŠKO – TEHNOLOŠKE OSNOVE
ZAŠTITE INFORMACIONIH SISTEMA

1. OSNOVI BEZBEDNOSTI INFORMACIONIH

SISTEMA........................................................................................2
0. UVOD......................................................................................2
1.BEZBEDNOST IKT SISTEMA....................................................4
1.2. Funkcionalna zavisnost bezbednosti i pretnji...................6
2. FAKTORI UTICAJA NA BEZBEDNOSNO STANJE
SAVREMENIH INFORMACIONIH SISTEMA..................10
2.1. Uticaj funkcionalnih zahteva poslovnih sistema.............10
2.2. Uticaj organizacione strukture.........................................11
2.3. Uticaj razvoja IK tehnologije............................................12
2.4. Uticaj ograniĉenog znaĉaja politike zaštite.....................13
2.5. Uticaj obuke i razvoja svesti o potrebi zaštite.................14
2.6. Faktori uticaja na praksu zaštite IKT sistema................15
3. REZIME.......................................................................................18
4. KLJUĈNI TERMINI..................................................................19
5. LITERATURA............................................................................22

2.METODOLOGIJE, MODELI I OKVIRI ZA RAZVOJ

SISTEMA ZAŠTITE ........................................................26
0. UVOD...........................................................................................26
1. METODOLOŠKI OKVIR ZA RAZVOJ SISTEMA
ZAŠTITE.....................................................................................26
2. METODOLOGIJE ZA RAZVOJ SISTEMA
ZAŠTITE..........................................................................................31
2.2. Metodologija vektora zaštite (S-vektora)........................32
2.3. Koncept metodologije S-vektora......................................32
2.4. Prednosti i nedostaci metodologije S-vektora.................34
3. MODELOVANJE SISTEMA ZAŠTITE..................................36
3.1. Strukturni modeli distribuiranog IKT sistema...............36
3.2. Problemi i nedostaci strukturnog modelovanja..............41
3.3. Osnovni pojmovi metodologije objektno orijentisanog
pristupa.............................................................................43
 3.4. Primena objektno-orijentisanog pristupa u oblasti
zaštite.................................................................................46
4. REZIME.......................................................................................48
5. KLJUĈNI TERMINI..................................................................51
6. LITERATURA............................................................................53

3. MODELI I OKVIRI ZA RAZVOJ SISTEMA ZAŠTITE

.............................................................................................24
0. UVOD...........................................................................................24
1. METODOLOŠKI OKVIR ZA RAZVOJ SISTEMA
ZAŠTITE................................................................................26
2. METODOLOGIJE ZA RAZVOJ SISTEMA ZAŠTITE........31
2.1. Opšta metodologija za razvoj programa i sistema
zaštite.................................................................................31
2.2. Metodologija vektora zaštite (S-vektora)........................32
2.3. Koncept metodologije S-vektora......................................32
2.4. Prednosti i nedostaci metodologije S-vektora.................34
3. MODELOVANJE SISTEMA ZAŠTITE..................................36
3.1. Strukturni modeli distribuiranog IKT sistema...............36
3.2. Problemi i nedostaci strukturnog modelovanja .............41
3.3. Osnovni pojmovi metodologije objektno
orijentisanog pristupa......................................................43
4. REZIME......................................................................................47
5. KLJUĈNI TERMINI.................................................................49
6. LITERATURA ...........................................................................51

4. PRINCIPI ZAŠTITE........................................................55
0. UVOD...........................................................................................55
1. SISTEMSKI PRINCIPI ZAŠTITE...........................................56
2. OPŠTE PRIHVAĆENI PRINCIPI ZAŠTITE (GAISP)..........57
2.1. Namena GAISP principa zaštite.......................................57
2.2. Struktura GAISP principa zaštite....................................58
2.3. Opšti principi zaštite..........................................................59
2.4. Funkcionalni principi zaštite............................................61
2.5. Potpuni principi zaštite.....................................................63
3. REZIME.......................................................................................64
4. KLJUĈNI TERMINI..................................................................65
5. LITERATURA............................................................................66
5. NORMATIVNI OKVIR I STANDARDI ZAŠTITE.....68
0. UVOD.......................,,..................................................................68
 1. NORMATIVNI OKVIR ZAŠTITE...........................................70
2. STANDARDI ZAŠTITE.............................................................73
2.1. Opšta definicija standarda zašt........................................74
2.2. Opšti model standarda za upravljanje zaštito................75
2.3. Klasifikacija standarda zaštite.........................................76
2.4. Prednosti i nedostaci standarda zaštite...........................79
2.5. Razvoj i implementacija standarda najbolje prakse
zaštite..................................................................................80
2.6. Uputsva i dokumenta zaštite.............................................84
3. ANALIZA RELEVANTNIH STANDARDA ZAŠTITE.........85
3.1. Standard ISO/IEC 17799 za upravljanje zaštitom ........85
3.2. Relevantni standardi za evaluaciju sistema zaštite ........88
3.2.1. Opšti kriterijumi za evaluaciju proizvoda zaštite..........88
3.2.2. SSE-CMM model i metod................................................89
3.2.3. Standard ISO/IEC 15504.................................................90
3.2.4. Ostali relevantni standardi..............................................90
4. REZIME.......................................................................................92
5. KLJUĈNI TERMINI..................................................................94
6. LITERATURA............................................................................95

6. DOKUMENTOVANJE PROGRAMA ZAŠTITE.........97

0. UVOD...........................................................................................97
1. KLASIFIKACIJA DOKUMENATA ZAŠTITE......................98
2. USPOSTAVLJANJE KONTROLNOG OKVIRA................100
2.1. Kontrolni okvir................................................................100
2.2. Uputsva za zaštitu............................................................101
2.3. Pregled i aţuriranje dokumenata zaštite.......................102
3. REZIME.....................................................................................103
4. KLJUĈNI TERMINI................................................................104
5. LITERATURA..........................................................................105

7. OPŠTI MODEL SERVISA ZAŠTITE.........................106

0. UVOD.........................................................................................106
1. SERVISI ZAŠTITE..................................................................108
1.1. Bezbednosna misija i ciljevi............................................108
1.2. MeĊuzavisnost bezbednosnih ciljeva.............................111
2. OPŠTI MODEL SERVISA ZAŠTITE....................................113
2.1. Servisi za podršku............................................................114
2.2. Servisi za zaštitu (spreĉavanje).......................................114
 2.3. Servisi za detekciju i oporavak.......................................116
2.4. Implementacija servisa zaštite u distribuiranom IKT
sistemu..............................................................................120
2.4.1. Bezbednosna pouzdanost sistema.................................121
2.4.2. Servisi zaštite operativnog sistema.. .............................121
2.4.3. Servisi zaštite u bezbednosnom domenu......................122
3. RAZVOJ I IMPLEMENTACIJA SERVISA ZAŠTITE.......125
3.1. Servisi poverljivog provajdera zaštite (TTPS)..............127
4. REZIME.....................................................................................129
5. KLJUĈNI TERMINI................................................................131
6. LITERATURA..........................................................................133

8. TEHNOLOGIJE ZA ZAŠTITU RAĈUNARSKIH

SISTEMA........................................................................134
0. UVOD ........................................................................................134
1. KLASIFIKACIJA ALATA ZA ZAŠTITU.............................136
2. HOST ORIJENTISANI MEHANIZMI ZAŠTITE................138
2.1. Bezbednosni slojevi raĉunarskog sistema......................138
2.2. (Pod)sistem za zaštitu OS................................................140
2.3. Autentifikacija i autorizacija..........................................141
2.4. Integritet raĉunarskog sistema.......................................143
2.4.1. Skeneri zaštite RS...........................................................143
2.4.2. Antivirusni programi.....................................................145
2.4.3. Skeneri sadrţaja.............................................................146
2.5. Kontrola pristupa raĉunarskom sistemu.......................147
2.5.1. Mehanizmi za upravljanje pristupom..................147
2.6. Monitoring zaštite raĉunarskih sistema........................149
2.6.1. Detektori upada u raĉunarski sistem...................149
2.6.2. Mehanizmi za upravljanje log datotekama ........151
2.7. Mehanizmi za zaštitu poverljivosti i integriteta
podataka...........................................................................153
2.7.1. Kriptografski mehanizmi...............................................153
2.7.2. Skeneri sadrţaja i e-mail filteri.....................................154
3. REZIME.....................................................................................155
4. KLJUĈNI TERMINI................................................................159
5. LITERATURA..........................................................................161

9. TEHNOLOGIJE ZA ZAŠTITU RAĈUNARSKIH

MREŢA...........................................................................162
 0. UVOD.........................................................................................162
1. MREŢNA AUTENTIFIKACIJA I AUTORIZACIJA..........164
1.1. Autentifikacioni protokoli...............................................164
1.2. Serveri za autentifikaciju i autorizaciju........................166
1.3. Integritet raĉunarske mreţe...........................................169
1.3.1. Skeneri zaštite raĉunarske mreţe.................................169
1.3.2. Skeneri telefonskih veza.................................................170
1.4. Kontrola pristupa raĉunarskoj mreţi............................172
1.4.1. Mreţne barijere (Firewalls)...........................................172
1.4.2. Proksi serveri..................................................................174
1.4.3. Web filteri........................................................................174
1.5. Monitoring mreţne zaštite..............................................175
1.5.1. Mreţni sistemi za detekciju upada.......................175
1.6. Poverljivost i integritet mreţnih podataka....................177
1.6.1. Kriptografski mehanizmi i protokoli...................177
1.7. Infrastrukturna komponenta mreţne zaštite...............180
1.7.1. Infrastruktura sa javnim kljuĉem (PKI)............180
1.7.2. Smart kartice i kriptografski moduli...................183
1.7.3. Autentifikacioni ureĊaji i protokol.......................185
1.8. Zaštita beţiĉno povezanih lokalnih mreţa (WLAN) ...186
2. REZIME.....................................................................................188
3. KLJUĈNI TERMINI................................................................191
4. LITERATURA..........................................................................193

10. KONCEPT KONTROLA SISTEMA ZAŠTITE

INFORMACIJA............................................................195
0. UVOD.........................................................................................195
1. POKRIVANJE PRETNJI KONTROLAMA ZAŠTITE.......197
1.1. Opis izvora pretnji...........................................................197
1.2. Procena pokrivanja prirodnih grešaka/dogaĊaja........197
2. ODREĐIVANJE KVALITETA KONTROLA ZAŠTITE....198
2.1. Osnovne karakteristike kontrola zaštite........................198
2.2. Struktura, organizacija i identifikacija kontrola zaštite
...........................................................................................200
2.2.1.Upravljaĉke kontrole zaštite..........................................201
2.2.2. Operativne kontrole zaštite...........................................202
2.2.3. Tehniĉke kontrole zaštite...............................................202
3. SISTEM KONTROLA ZA OSNOVNU ZAŠTITU...............204
4. PROCES SELEKCIJE KONTROLA ZAŠTITE...................207
 4.1. Izbor osnovnih kontrola zaštite......................................207
4.2. Kreiranje skupa kontrola osnovne zaštite....................211
4.3. Osnovne aktivnosti za implementaciju kontrola zaštite
..........................................................................................212
4.4. Dokumentovanje kontrola zaštite u planu zaštite
...........................................................................................213
5. KATALOG KONTROLA OSNOVNE ZAŠTITE.................214
5.1. Sistem kontrola osnovne zaštite......................................214
6. REZIME.....................................................................................215
7. KLJUĈNI TERMINI................................................................218
8. LITERATURA..........................................................................219

II GLAVA
RAZVOJ PROGRAMA ZAŠTITE
INFORMACIONIH SISTEMA

1. PRETNJE I RIZICI ZA INFORMACIONE SISTEME

..........................................................................................221
0. UVOD.........................................................................................221
1. PRETNJE I NAPADI...............................................................223
1.1. Taksonomije pretnji i napada........................................223
1.2. Pregled procena gubitaka i vrsta napada......................228
2. PREGLED MALICIOZNIH PROGRAMA...........................233
2.1. Virusi.................................................................................234
2.2. Trojanci............................................................................240
2.3. Crvi (Worms)....................................................................241
2.4. Mobilni (aktivni) kôdovi..................................................242
2.5. Kombinovani napad (Blended Attack) ..........................242
3. MERE ZAŠTITE I OPORAVAK SISTEMA OD NAPADA
.....................................................................................................243
4. REZIME.....................................................................................245
5. KLJUĈNI TERMINI................................................................247
6. LITERATURA..........................................................................248
2. KONCEPTI ZA RAZVOJ PROGRAMA I SISTEMA
ZAŠTITE.............................................................................250
0. Uvod............................................................................................250
1. KONCEPT REAKTIVNOG SISTEMA ZAŠTITE...............252
1.1. Koncept reaktivne zaštite................................................252
1.1.1. Funkcionalni model koncepta reaktivne zaštite..254
1.1.2. Ocena kvaliteta sistema reaktivne zaštite............256
2. KONCEPT PROAKTVNE ZAŠTITE....................................260
2.1. Funkcionalni model proaktivne zaštite..........................262
2.2. Ocena kvaliteta proaktivne zaštite.................................268
3.REZIME......................................................................................269
4. KlJUĈNI TERMINI..................................................................270
5. LITERATURA..........................................................................272

3. PROCESI I PROCEDURE ZAŠTITE..........................274

0. UVOD.........................................................................................274
1. PROCESI I PROCEDURE ZAŠTITE....................................275
1.1. Procesi zaštite...................................................................275
1.2. Generiĉki proces sistema zaštite.....................................278
1.3. Procedure zaštite..............................................................279
2. STABILNOST PROCESA ZAŠTITE.....................................281
2.1. Produktivnost...................................................................281
2.2. Adaptivnost......................................................................282
2.3. Korisniĉka prihvatljivost................................................283
3. POBOLJŠAVANJE PROCESA ZAŠTITE............................284
3.1. Metodi za poboljšavanje procesa....................................284
3.2. Poboljšavanje produktivnosti ........................................285
3.2.1. Poboljšavanje efektivnosti procesa...............................286
3.2.1. Poboljšavanje efikasnosti procesa.................................286
3.2.2. Smanjenje ciklusa ponavljanja procedure
.................................................................................288
3.3. Poboljšavanje adaptivnosti.............................................289
3.3.1. Poboljšavanje fleksibilnosti...................................289
3.3.2. Poboljšavanje skalabilnosti...................................290
3.4. Poboljšavanje korisniĉke prihvatljivosti.......................291
3.4.1. Kulturološki uticaj.........................................................291
3.4.2. Smanjenje kompleksnosti..............................................292
3.4.3. Uticaj psiholoških faktora.............................................293
4. REZIME.....................................................................................294
 5. KLJUĈNI TERMINI...........................................................296
6. LITERATURA....................................................................297

4. PROCESNI OKVIR ZA RAZVOJ PROGRAMA

ZAŠTITE.........................................................................298
0. UVOD.........................................................................................298
1. OSNOVI SSE CMM METODOLOGIJE...............................300
1.1. Osnovni problemi SSE....................................................300
1.2. Generiĉka struktura SSE CMM modela i metoda.......301
1.3. Struktura Integralnog kataloga oblasti procesa SSE
CMM modela ...................................................................307
1.4. Mogućnosti primene SSE CMM u oblasti zaštite..........309
1.5. Koncept redukovanog SSE CMM za razvoj programa
zaštite...............................................................................312
2. PROGRESIVNO SAZREVANJE KAPACITETA ZA
RAZVOJ PROGRAMA ZAŠTITE.........................................313
3. MERENJE ZRELOSTI PROCESA ZAŠTITE......................317
4. REZIME.....................................................................................319
5. KLJUĈNI TERMINI................................................................320
6. LITERATURA..........................................................................321

5. RAZVOJ STRATEŠKOG PLANA ZAŠTITE.............322

0. UVOD.........................................................................................322
1. RAZVOJ STRATEGIJE ZAŠTITE........................................323
1.1. Ciklus strateškog planiranja zaštite...............................325
1.2. Proces razvoja strateškog plana zaštite.....................332
2. REZIME.....................................................................................336
3. KLJUĈNI TERMINI................................................................337
4. LITERATURA..........................................................................338

6. STRUKTURA PROGRAMA I PLANA ZAŠTITE.....339

0. UVOD.........................................................................................339
1. STRUKTURA PROGRAMA ZAŠTITE................................340
1.1. Proces razvoja i struktura plana zaštite........................342
1.1.1. Uloge i odgovornosti......................................................343
1.1.2. Upravljanje promenama...............................................347
1.2. Struktura politika i procedura zaštite...........................349
1.2.1. Definicija i namena politike zaštite..............................349
1.2.2. Taksonomija politika zaštite........................................350
1.2.3. Struktura procedura zaštite.........................................352
 2. REZIME.....................................................................................354
3. KLJUĈNI TERMINI................................................................355
4. LITERATURA..........................................................................356

7. RAZVOJ POLITIKA I PROCEDURA ZAŠTITE......358

0. UVOD.........................................................................................358
1. METODOLOGIJA ZA IZRADU POLITIKE ZAŠTITE.....360
1.1. PRAKTIĈNI PRINCIPI ZA DIZAJNIRANJE
POLITIKE ZAŠTITE.......................................................360
1.2. Autori izrade kontrolnog okvira....................................362
1.3. Standardi za izradu politike zaštite...............................363
1.4. Opšti model za izradu politike zaštite...........................365
1.5. Preporuke za izradu politike zaštite..............................366
2. IZRADA POLITIKE ZAŠTITE.............................................368
2.1.Osnovni atributi politike i procedure zaštite.................368
2.2. Osnovni kriterijumi za izradu politike zaštite..............369
2.3. Izraţavanje znaĉaja politika zaštite...............................370
2.4. Identifikovanje i definisanje saopštenja politike zaštite
...........................................................................................371
2.4.1. Identifikovanje strukture Programa zaštite........372
2.4.2. Politika zaštite na nivou IKT sistema...........................373
2.4.3. Politika zaštite funkcionalnih komponenti ................375
2.5. Razvoj procedura zaštite.................................................378
2.6. Implementacija politike, standarda, uputstava i
procedura zaštite.............................................................380
3. REZIME....................................................................................381
4. KLJUĈNI TERMINI...............................................................383
5. LITERATURA.........................................................................384

8. IMPLEMENTACIJA I INTEGRACIJA PROGRAMA

ZAŠTITE........................................................................386
0. UVOD.........................................................................................386
1. OPŠTI METOD IMPLEMENTACIJE
PROGRAMA/SISTEMA ZAŠTITE...........................................387
2. IMPLEMENTACIJA PROGRAMA ZAŠTITE....................391
2.1. Obuka zaposlenih............................................................392
2.2. Kontrola usklaĊenosti.....................................................394
2.3. Interni nadzor i kontrola................................................397
2.4. Eksterna kontrola (auditing)...........................................399
 2.5. Izveštavanje o kontroli zaštite........................................400
2.6. Nametanje obaveze izvršavanja i izveštavanja.............402
3. REZIME.....................................................................................403
4. KLJUĈNI TERMINI................................................................404
5. LITERATURA..........................................................................406

9. METRIĈKI SISTEMI U OBLASTI ZAŠTITE

INFORMACIJA..............................................................408
0. UVOD.........................................................................................408
1. METODOLOGIJA SISTEMA MERENJA ZAŠTITE
INFORMACIJA………………………………………….......409
1.1. Definicije pojmova..........................................................409
1.2. Principi, namena i proces metriĉkog sistema...............411
1.3. Procesno-rezultatski orijentisan metriĉki sistem zrelosti
procesa zaštite................................................................412
2. RAZVOJ PROGRAMA METRIĈKOG SISTEMA
ZAŠTITE.............................................................................418
2.1. Struktura programa metriĉkog sistema zaštite...........418
2.2. Izbor tipa metriĉkog sistema.........................................419
2.3. Proces razvoja i implementacije programa metrike
zaštite..............................................................................420
3. PREDNOSTI I NEDOSTACI METRIĈKIH SISTEMA
ZAŠTITE..................................................................................422
4. REZIME...................................................................................423
5. KLJUĈNE REĈI.....................................................................424
6. LITERATURA........................................................................425
III GLAVA
UPRAVLJANJE ZAŠTITOM
INFORAMACIONIH SISTEMA
1. UPRAVLJANJE ZAŠTITOM INFORMACIJA.........428
0. UVOD.........................................................................................428
1. METODOLOGIJA UPRAVLJANJA ZAŠTITOM...........430
1.1. Principi upravljanja zaštitom........................................430
1.2. Uloge i odgovornosti........................................................431
1.3. Implementacija principa zaštite u program i sistem
zaštite................................................................................432
1.4. Procesi upravljanja sistemom zaštite informacija…....433
1.4.1. Generiĉki proces upravljanja sistemom zaštite
informacija (ISM)………...……...................................433
1.4.2. Integralni proces upravljanja IKT i sistema zaštite..434
1.5. Upravljaĉke kontrole najbolje prakse zaštite...............437
1.6. Administracija zaštite u distribuiranom OSI sistemu 439
1.7. Razvoj metrike za evaluaciju upravljanja sistemom
zaštite................................................................................440
2. OTVORENI PROBLEMI UPRAVLJANJA ZAŠTITOM
INFORMACIJA........................................................................443
3. PREPORUKE ZA UPRAVLJANJE ZAŠTITOM…............447
4. REZIME……………………………………………................448
5. KLJUĈNI TERMINI…………………..………………….....450
6. LITERATURA……………………..……………………........451

2. UPRAVLJANJE BEZBEDNOSNIM RIZIKOM U

INFORMACIONOM SISTEMU………………………...453
0.UVOD……………………………………………………..........453
1. OPŠTA METODOLOGIJA UPRAVLJANJA RIZIKOM
....................................................................................................455
1.1. Glavni principi upravljanja rizikom u IKT sistemu
..........................................................................................455
1.2. Opšti model analize rizika...............................................459
1.3. Zajedniĉki osnovi procesa upravljanja ...................460
1.4. Formalna metodologija procene rizika...................462
1.5. Opšti metod procene rizika.............................................464
1.5.1. Procena vrednosti objekata – A............................465
 1.5.2. Procena pretnji –T.................................................466
1.5.3. Procena ranjivosti sistema –V..............................470
1.5.4. Procena uticaja pretnji na ranjivosti sistema …473
1.6. Proraĉun faktora preostalog rizika metodom
rentabiliteta......................................................................476
2. REZIME....................................................................................479
3. KLJUĈNI TERMINI...............................................................481
4. LITERATURA.........................................................................483

3. UPRAVLJANJE PERSONALNOM ZAŠTITOM.......485

0. UVOD.........................................................................................485
1. PROCES POPUNE RADNIH MESTA U IKT SISTEMU...486
1.1. OdreĊivanje osetljivosti radnog mesta .........................487
1.2. Popuna radnih mesta – bezbednosna zaštita i izbor
zaposlenih...............................................................................487
1.3. Obuka zaposlenih............................................................488
2. UPRAVLJANJE PERSONALNOM ZAŠTITOM................489
2.1. Upravljanje korisniĉkim nalozima................................489
2.2. Kontrola (auditing) prakse upravljanja korisniĉki
nalozima............................................................................491
2.3. Detekcija neovlašćenih/ilegalnih aktivnosti zaposlenih
............................................................................................491
2.4. Privremena zamena i interni transferi zaposlenih
.................................................................................491
2.5. Ukidanje naloga..............................................................492
2.6. Personalna zaštita spoljnih saradnika po ugovoru.......493
2.7. Personalna zaštita u IKT sistemu sa javnim pristupo..493
3. MEĐUZAVOSNOST SA PRIMARNIM SERVISIMA
ZAŠTITE....................................................................................494
4. REZIME.....................................................................................495
5. KLJUĈNI TERMINI................................................................496
6. LITERATURA..........................................................................497
4. UPRAVLJANJE FIZIĈKO TEHNIĈKOM ZAŠTITOM
...............................................................................................498
0. UVOD.........................................................................................498
1. STANDARDI FIZIĈKE ZAŠTITE.........................................499
1.1. Standardi fiziĉke zaštite za raĉunarsku sobu i radne
stanice................................................................................499
2. FIZIĈKA ZAŠTITA IKT SISTEMA I ZAŠTITA
OKRUŢENJA............................................................................500
2.1. Rizici proboja fiziĉke zaštite i zaštite okruţenja IKT sistema
..................................................................................................500
2.2. Fiziĉka zaštita IKT sistema i okruţenja...............................501
2.3. Zaštita EM i optiĉkih medija................................................506
2.3.1. Metodi fiziĉke zaštite i uništavanja medija ........507
2.4. Metod implementacije fiziĉke zaštite...................................509
3. KONVERGENCIJA FIZIĈKE I LOGIĈKE KONTROLE
PRISTUPA.......................................................................................511
3.1. Integracija kontrola fiziĉkog i logiĉkog pristupa................512
4. MEĐUZAVISNOST SA DRUGIM SERVISIMA ZAŠTITE......515
5. REZIME...........................................................................................516
6. KLJUĈNI TERMINI.......................................................................518
7. LITERATURA.................................................................................519

5. UPRAVLJANJE OBUKOM I EDUKACIJOM O

ZAŠTITI .........................................................................520
0. UVOD.........................................................................................520
1. RAZVOJ SVESTI O POTREBI ZAŠTITE, OBUKA I
OBRAZOVANJE U ZAŠTITI.................................................522
1.1. Definisanje programa za razvoj svesti o potrebi i obuku o
zaštiti.................................................................................522
1.2. Program za razvoj svesti o potrebi zaštite....................524
1.3. Program obuke o zaštiti..................................................525
1.4 Obrazovanje u zaštiti.......................................................527
1.5 Kontinuitet procesa obrazovanja o zaštiti......................528
2. UPRAVLJANJE PROGRAMOM OBUKE O ZAŠTITI......529
3. PROCES RAZVOJA PROGRAMA OBUKE O ZAŠTITI ..532
3.1. Priprema za razvoj programa........................................533
3.2. Projektovanje programa zaštite.....................................535
3.3. Implementacija programa..............................................537
3.4. Evaluacija programa.......................................................539
 4. MEĐUZAVISNOST SA DRUGIM KONTROLAMA
ZAŠTITE....................................................................................540
5. REZIME.....................................................................................541
6. KLJUĈNI TERMINI................................................................543
7. LITERATURA..........................................................................544

6. UPRAVLJANJE KONFIGURACIJOM......................545
0. UVOD........................................................................................545
1. PROCES UPRAVLJANJA PROMENAMA
KONFIGURACIJE..............................................................547
1.1. Pregled principa za upravljanje konfiguracijom..........547
1.2. Zahtev za promene...........................................................549
1.2.1. Zahtev za hitne promene.......................................549
2. RAZVOJ PROCEDURA ZA PROCES UPRAVLJANJA
KONFIGURACIJOM...............................................................550
2.1. Izrada plana za upravljanje promenama konfiguracije
..........................................................................................551
2.1.1. Izrada plana za upravljanje promenama objekata
IKT sistema............................................................551
2.1.2. Izrada plana za ispitivanje promena ..................582
2.2. Upravljanje promenama osnovne konfiguracija IKT
sistema...............................................................................553
2.3. Upravljanje promenama u IKT sistemu.....................553
2.4. Upravljanje promenama servisa za kontrolu pristupa
...........................................................................................554
2.5. Monitorisanje promena...................................................555
2.6. Konfigurisanje minimuma servisa.................................555
2.7. Kontrola i verifikacija bezbedne konfiguracije............556
2.8. Upravljanje konfiguracijom raĉunarske mreţe............556
2.9. Politika zaštite privatnosti..............................................557
2.10. Ograniĉavanje tipova saobraćaja................................557
3. REZIME....................................................................................558
4. KLJUĈNI TERMINI...............................................................560
5. LITERATURA.........................................................................561
7. UPRAVLJANJE KOMPJUTERSKIM INCIDENTOM
...........................................................................................563
0. UVOD.........................................................................................563
1. KOMPJUTERSKI DOGAĐAJ I KOMPJUTERSKI
INCIDENT……………………………….....................................565
1.2. Politike i procedure za upravljanje incidentom............567
1.3. Kategorije bezbednosnog kompjuterskog incidenta....568
1.4. Nagoveštaji kompjuterskog incidenta...........................569
2. UPRAVLJANJE KOMPJUTERSKIM INCIDENTOM…..571
2.1. Pripremna faza................................................................572
2.2 Detekcija i analiza incidenta...........................................575
2.3. Saniranje posledica i oporavak sistema........................576
2.4. Analiza iskustava ...........................................................577
3. REZIME...................................................................................580
4. KLJUĈNI TERMINI..............................................................582
5. LITERATURA........................................................................584

8. UPRAVLJANJE VANREDNIM DOGAĐAJEM........585

0. UVOD.........................................................................................585
1. PROCES UPRAVLJANJA VANREDNIM DOGAĐAJEM
....................................................................................................586
1.1. Proces planiranja vanrednih dogaĊaja...................586
2. MEĐUZAVISNOSTI SA DRUGIM KONTROLAMA
ZAŠTITE....................................................................................598
3. REZIME.....................................................................................599
4. KLJUĈNI TERMINI................................................................601
5. LITERATURA..........................................................................602

9. NADZOR I KONTROLA SISTEMA ZAŠTITE.........604

0. UVOD.........................................................................................604
1. PREGLED PRINCIPA KONTROLE SISTEMA
ZAŠTITE..................................................................................606
1.2 Aspekti efektivnog procesa kontrole zaštite ........607
2. RAZVOJ STRATEGIJE ZA NADZOR I KONTROLU
ZAŠTITE IKT SISTEMA...................................................................609
3. REZIME.....................................................................................621
4. KLJUĈNI TERMINI................................................................623
5. LITERATURA..........................................................................624
10. SERTIFIKACIJA I AKREDITACIJA SISTEMA
ZAŠTITE.......................................................................625
0. UVOD.........................................................................................625
1. METODOLOGIJA PROCESA SERTIFIKACIJE I
AKREDITACIJE.................................................................626
1.1. Uloge i odgovornosti…………………………................626
1.2. Bezbednosna kategorizacija IKT sistema za C&A..….629
1.3. Kategorije akreditacije...................................................630
1.4. Sertifikaciona i akreditaciona dokumentacija…..........632
2. UPRAVLJANJE PROCESOM SERTIFIKACIJE I
AKREDITACIJE................................................................634
2.1 Faza pred-sertifikacije.....................................................634
2.2 Faza sertifikacije……………………………..….............635
2.3 Faza akreditacije...............................................................638
2.4. Faza post-akreditacije.....................................................640
3. REZIME.....................................................................................641
4. KLJUĈNI TERMINI................................................................643
5. LITERATURA..........................................................................644
 UVOD
Produktivnost savremenih poslovnih sistema u najvećoj meri
zavisi od brzine donošenja odluka i kvaliteta upravljanja. Odluĉivanje, a
time i kvalitet upravljanja u potpunosti zavise od kvaliteta informacija,
koje procesiraju, skladište i prenose informaciono komunikacioni sistemi
(IKT sistemi), ili informacioni sistemi (IS).

U skladu sa objektno orijentisanim pristupom, od brojnih atributa

informacija, kvalitet informacija u potpunosti zavisi od skupa relativno
nezavisnih atributa: poverljivosti informacija, ili da informacije nisu
otkrivene neovlašćenim korisnicima; integriteta informacija, ili da
informacije nisu neovlašćeno izmenjene i raspoloživosti informacija,
odnosno, da su informacije dostupne legitimnim korisnicima kada je to
potrebno.

Kvalitet procesiranih, skladištenih i prenošenih informacija u

savremenim visoko distribuiranim i umreţenim IKT sistemima Internet
tipa zavisi od bezbednosti sistema i njegovog okruţenja, odnosno, od
implementiranog sistema zaštite. Na taj naĉin, pored kvaliteta hardvera i
softvera, bezbednost IKT sistema postaje treći gradivni blok sistema
kvaliteta poslovnih IKT sistema, odnosno, poslovnih sistema u celini.

Udţbenik Osnovi bezbednosti i zaštite informacionih sistema-razvoj i

upravljanje programaom zaštite-, namenjen je studentima završnih
godina i studentima specijalistiĉkih i poslediplomskih studija, ali i
korisnicima i menadţerima koji prvi put ulaze u problematiku zaštite
informacija. Mogu ga koristiti i profesionalci u zaštiti koji ţele
sistematizovati i upotpuniti svoja znanja iz ove široke, multidisciplinarne
oblasti.

Glavni cilj pisanja ovog udţbenika bio je da se raznovrsna i obimna

teorija, dostupna uglavnom u brojnoj stranoj literaturi, struĉnim
ĉasopisima, preporukama, uputstvima, standardima i autorskim radovima
na Internetu, sistematizuje, terminološki ujednaĉi i definiše i što je
moguće više pribliţi proseĉnim korisnicima i menadţerima koji po
pravilu ne moraju biti tehniĉki obrazovani. Smanjenje kompleksnosti
terminologije zaštite jedan je od strateških ciljeva teorije i prakse zaštite.
Time se postiţe veća razumljivost i korisniĉka prihvatljivost zaštite.
Brojni grafiĉki, funkcionalni, strukturni i objektno orijentisani modeli,
uzorci i primeri dati u udţbeniku i Praktikumu, koji je sastavni deo
udţbenika, takoĊe, smanjuju kompleksnost IKT sistema i sistema zaštite i
povećavaju korisniĉku prihvatljivost, posebno menadţerskih struktura,
koje mogu lakše prihvatiti zaštitu IKT sistema kao proizvodno ulaganje
za stvaranje novih vrednosti u organizaciji, a ne kao suvišne i neizvesne
troškove, što je tipiĉan sluĉaj u većini organizacija.

Metodološki, udţbenik je koncipiran u dve odvojene celine: teoretski

deo udţbenika i Praktikum. Udţbenik se sastoji od tri glave: Metodološko
tehnološke osnove zaštite IS, Razvoj programa zaštite IS i Upravljanje
zaštitom IS, sa ukupno 29 poglavlja. Praktikum se, takoĊe, sastoji od tri
dela: Pitanja za ponavljanje, Vežbe i Odgovori. Svako poglavlje
koncipirano modularno, sa: uvodom, razradom razmatranog problema,
rezimeom (kratkim sadrţajem), kljuĉnim terminima i spiskom korišćene i
šire literature.

Sa metodološkog aspekta, za obradu celokupne problematike zaštite u

zadatom okviru udţbenika korišćeni su i razmatrani sledeći kljuĉni
koncepti:
Koncept terminologije zaštite, kao jedan od glavnih ciljeva udţbenika
primenjen je u svakom poglavlju sa posebnim definisanjem kljuĉnih
termina na kraju poglavlja.
Koncept strateškog (dugoroĉnog) i taktičkog (kratkoroĉnog) rešavanja
problema bezbednosti i zaštite IKT sistema (planiranja i razvoja
programa, plana i sistema zaštite).
Koncept reaktivnih, tradicionalnih sistema zaštite koji štite informacije i
objekte IKT sistema od poznatih pretnji i proaktivnih sistema zaštite koji
štite informacije od poznatih i nepoznatih, dinamiĉki promenljivih,
kombinovanih pretnji.
Koncept sistemskog i procesnog pristupa, kojim se definišu i
identifikuju upravljaĉki, operativno-organizacioni i tehniĉki procesi
zaštite i razvijaju, implementiraju i poboljšavaju do ţeljenog nivoa
stabilnosti i zrelosti procesa (produktivnosti, adaptivnosti i korisniĉke
prihvatljivosti). Sistemski i procesni pristup zaštiti znaĉajan je i zato što
obezbeĊuje osnovu za dalji rad u ovoj oblasti i omogućava projektantima
IKT sistema i sistema zaštite da lakše usklade razvoj ţivotnih ciklusa
IKT sistema i sistema zaštite sa bolje definisanim i poznatim procesima i
metodima, što u praksi najĉešće nije sluĉaj – sistem zaštite se uglavnom
implementira pri kraju ili posle razvoja ţivotnog ciklusa IKT sistema. U
ovom kontekstu posebno detaljno razmatran je model progresivnog
sazrevanja procesa zaštite i metod merenja zrelosti i poboljšanja procesa
zaštite (SSE CMM- System Security Engineering Capability Maturity
Model).
Koncept objektno orijentisanog pristupa modelovanju IKT sistema, kao
objekta zaštite i sistema zaštite kao objekta (sredstava) za zaštitu
primenjen je u udţbeniku u cilju smanjenja kompleksnosti IKT sistema i
sistema zaštite. Detaljno je opisana primena objektno orijentisanog
modelovanja u oblasti zaštite. Primenom ovog pristupa identifikovane su
dve kljuĉne grane objekata: grana objekata zaštite - poverljivost,
integritet i raspoloživost informacija i grana objekata za zaštitu
(sredstava za zaštitu) – upravljačke, operativne i tehničke kontrole
zaštite. TakoĊe su razmatrane primene ostalih atributa objektno
orijentisanog pristupa na oblast zaštite: klase, objekti, komponente
objekta, kontejner, inkapsulacija, polimorfizam, nasleĎivanje i nivo
dekompozicije. Primena koncepta objektno orijentisanog modelovanja na
oblast zaštite ima višestruki znaĉaj, a posebno treba istaći da se
problematika zaštite na elegantan naĉin dovodi u fokus vlasnika i
projektanata IKT sistema, koji sada mogu istom metodologijom
blagovremeno uskladiti razvoje ţivotnih ciklusa IKT sistema i sistema
zaštite.
Koncept „Praktikuma“ primenjen je u udţbeniku da bi se kroz razliĉite
forme pitanja za ponavljanje i veţbe razliĉite teţine, teoretska znanja
razvila do odreĊenog stepena veštine i obuĉenosti studenata. Opšte je
poznato da bogate baze znanja, ukljuĉujući i brojne, relevantne standarde
zaštite, uglavnom nude „šta― treba uraditi u oblasti zaštite, dok su
malobrojne instrukcije o tome „kako― to treba uraditi. Veţbe (ukupno
26) koncipirane su od jednostavnih, gde je dovoljno savladati teoretsko
gradivo iz odgovarajućeg poglavlja udţbenika, do sloţenih koje
zahtevaju kreativan pristup, za napredne i zainteresovane studente.

U I Glavi definisani su i opisani u 10 poglavlja: kljuĉni termini u zaštiti

(bezbednost, zaštita, sistem zaštite, optimalna zaštita i.t.d.); koncepti
reaktivne i proaktivne zaštite; metodologije zaštite (opšta, vektora zaštite,
upravljanja rizikom, upravljanja zaštitom i.t.d.); modeli zaštite (klasiĉni
modeli za projektovanje IS, strukturni, funkcionalni, objektno
orijentisanog pristupa i dr.); strategija zaštite; principi (GAISP, OECD,
NIST) i brojni standardi zaštite (ISO/IEC 17799, Code of Practice and
Security Controles; ISO/IEC 21827 ili SSE CMM - System Security
Engineering Capability Maturity Model; ISO/IEC 15408, Evaluation
Criteria for IT Security („Common Criteria―) i drugi; dokumentacija
zaštite (program, plan, politike, procedure i uputstva); servisi zaštite
(primarni, sekundarni, opšti); tehnologije zaštite (tehniĉke kontrole
zaštite raĉunarskih sistema i raĉunarskih mreţa) i koncept upravljaĉkih
operativnih i tehniĉkih kontrola zaštite.

U II Glavi, Razvoj programa zaštite, u 9 poglavlja teţišno su obraĊene

kljuĉne metodologije za razvoj i implementaciju programa zaštite,
odnosno, plana, politika i procedura zaštite, ukljuĉujući sve tri grane
objekata upravljaĉkog okvira zaštite: upravljačke, operativne i tehničke
kontrole zaštite. Na kraju ove glave u posebnom poglavlju razmatrani su
relevantni metriĉki sistemi u oblasti zaštite, neophodni za ocenu kvaliteta
sistema zaštite i procese upravljanja zaštitom.

U III Glavi, Upravljanje zaštitom, u 10 poglavlja detaljno su razmatrane

upravljaĉke i operativne kontrolne komponente zaštite. Naime, u
upravljaĉkim i operativnim kontrolama zaštite ljudski faktor je
nezamenljiv i odluĉujući, a dobra praksa zaštite potvrdila je da se najbolji
rezultati u zaštiti postiţu, ako se ove kontrole kombinuju i razvijaju i
implementiraju jedinstveno. U teoriji i praksi zaštite proces upravljanja
sistemom zaštite generalno je najslabije razvijen proces zaštite. U tom
smislu, posebno su razmatrani procesi: upravljanja sistemom zaštite
integrisanim u IS, upravljanja samo sistemom zaštite i upravljanja
brojnim komponentama sistema zaštite - rizikom, fiziĉkom i
personalnom zaštitom, kompjuterskim incidentom, vanrednim dogaĊajem
i evaluacijom kvaliteta sistema zaštite (sertifikacijom i akreditacijom).
 I GLAVA
METODOLOŠKO – TEHNOLOŠKE OSNOVE
ZAŠTITE INFORMACIONIH SISTEMA

-1-
 1. OSNOVI BEZBEDNOSTI INFORMACIONIH
SISTEMA
0. UVOD

Po završetku ovog poglavlja razumećete:

- značaj usvajanja terminologije zaštite

- semantičko značenje termina «bezbednost» i «zaštita»
- osnovnu funkcionalnu zavisnost «bezbednosti» i «zaštite»
- funkcionalnu zavisnost «bezbednosti» i «pretnji»
- ključne faktore bezbednosnog stanja IKT sistema

Termini bezbednost informacionih sistema - IS i bezbednost

informaciono komunikacionih sistema - (IKT sistema), koriste se
ravnopravno, s tim da prvi termin prejudicira da informacione
tehnologije ukljuĉuju i komunikacione, drugi termin eksplicitno
naglašava ukljuĉivanje bezbednosti komunikacione infrastrukture IS.
Oba termina odnose se direktno na bezbednost informacija i podataka u
IS, kao najznaĉajnijih resursa svake organizacije (polovnog sistema), ali
i na bezbednost objekata računarskog sistema-RS i ili računarske mreže-
RM, a iz samog konteksta vidi se na šta se razmatranje konkretno odnosi.
Ovakav pristup implicira da je krajnji cilj oblasti bezbednost i zaštite –
zaštita informacija i podataka, koja se direktno ili posredno postiţe
zaštitom objekata IS. Objekte IS, odnosno, objekte zaštite u kontekstu
bezbednosti i zaštite, ĉine: korisniĉke informacije i podaci-korisnički
objekti, hardver RS i RM, elektro magnetski i optiĉki mediji za
skladištenje informacija-fizički objekti, aplikativni i sistemski programi-
logički objekti i okruţenje IS (smeštajni objekat-zgrada, sistemi za
grejanje, hlaĊenje, PPZ, video nadzor, protivprovalnu zaštitu i.t.d.). U
praksi najĉešće se koristi termin „bezbednost informacija― (eng.
information security, rus. безопасност информации, srpski, bezbednost
podataka i imnformacija), koji svakako implicira bezbednost svih fiziĉkih
i logiĉkih objekata IS, koji procesiraju, skladište ili prenose podatke i
informacije. Termin bezbednost i zaštita IKT sistema implicira da su
obezbeĊeni (zaštićeni) u najširem smislu informacije, svi objekti RS,
komunikacije i mreţna infrastruktura IS. Najznaĉajniji pojmovi i termini
korišćeni u ovom udţbeniku definisani su na kraju svake glave u
poglavlju „Ključni termini―. U svakom konkretnom poglavlju definisani
su samo pojmovi i termini relevantni za dato razmatranje.

-2-
Generalno, tendencija je da se terminologija oblasti zaštite informacija
što je moguće više pojednostavi i pribliţi krajnjim korisnicima.
Smanjenjem kompleksnosti terminologije u oblasti bezbednosti i zaštite
informacija, znaĉajno se povećava korisniĉka prihvatljivost, brţe razvija
svest o potrebi zaštite i obezbeeĊuje neophodna podrška rukovodstva
organizacije za program zaštite. Razumevanje semantiĉkog znaĉenja
pojma bezbednosti informacija, i faktora koji utiĉu na tu bezbednost
omogućava korisnicima i vlasnicima sistema da shvate značaj i potrebu
zaštite.

U praksi zaštite postoje brojne definicije bezbednosti informacija,

zavisno od nivoa apstrakcije. Na nivou drţave to je: „Stanje zaštićenosti
nacionalnih interesa u informacionoj sferi, odreĎenih skupom ličnih,
poslovnih i državnih interesa―. Bezbednost informacija obezbeĊuje se
zaštitom informacija. Otuda se bezbednost i zaštita informacija moţe
definisati kao: „Zaštićenost informacija i objekata IKT sistema od
slučajnih ili namernih aktivnosti (akcija, dejstava, uticaja) prirodnog ili
veštačkog karaktera koje mogu naneti neprihvatljivu štetu
informacijama, korisnicima ili vlasnicima informacija i objektima
infrastrukture IKT sistema―, [6].

-3-
1. BEZBEDNOST IKT SISTEMA

1.1. Definicije pojma bezbednost IKT sistema

Bezbednost IKT sistema je objektivna mera/ocena stanja rizika

IKT sistema ili stanja sigurnog, pouzdanog i neometanog funkcionisanja
sistema u odnosu na sam sistem ili njegovo okruţenje. Sistem se smatra
bezbednim, ako je obezbeĊen-zaštićen od uticaja faktora pretnji-rizika.
Sigurnost IKT sistema u srpskom jeziku je sinonim bezbednosti, a moţe
se definisati kao subjektivna mera osećaja sigurnosti (uverenja) korisnika
da je sistem bezbedan. U kontekstu opšte prakse zaštite termin sigurnost
sistema zaštite semantiĉki najbliţe odgovara znaĉenju engleskog termina
Assurance (bezbednosna garancija, ili bezbednosna pouzdanost, ili
pouzdanost da je obezbeĊena zaštićenost IKT sistema), koji odraţava
subjektivni osećaj - uverenje da je sistem bezbedan ili poverenje u
zaštićenost koju sistem nominalno poseduje.

Oĉigledno, definicije termina «bezbednost» i «poverenje», zasnivaju se

na mehanizmu ljudske percepcije, odnosno, IKT sistem se smatra
bezbednim ako je do odreĎenog stepena pouzdano poznato da zaista
poseduje neka bezbednosno relevantna svojstva koja nominalno
poseduje, a poverljiv je, ako se do odreĎenog stepena veruje da stvarno
poseduje neka bezbednosno relevantna svojstva koja nominalno
poseduje. U oba sluĉaja termin «do odreĎenog stepena» indicira
relativnost (stepen neodreĊenosti) definicija pojmova poverenja i
bezbednosti.

Sa aspekta bezbednosti u realnom okruženju, IKT sistem je sloţeni

sistem sa sociološko- kulturološkim i tehnološkim faktorima. U tom
smislu za ocenu bezbednosnog stanja treba ukljuĉiti bezbednosne aspekte
iz svih pomenutih kategorija. U kvalifikovanju i oceni bezbednosnog
stanja koristi se termin nivo bezbednosnog stanja, koji se odreĊuje
nivoom preostalog i prihvatljivog rizika. U opštem sluĉaju, ukupna
bezbednost nekog sloţenog sociološko-kulturološko-tehnološkog sistema
u kontekstu realnog okruţenja, obuhvata skup komponenti (elemenata)
bezbednosti iz razliĉitih sfera, kao što su (poreĊane po relativnom
znaĉaju): državna-B1, vojna-B2, ekonomska-B3, socijalna-B4, ekološka-
B5, kulturološka-B6, tehnička-B7, informaciono-kibernetička-B8 i.t.d.
Nivo ukupne bezbednosti sloţenog sistema-Bu raste sa porastom nivoa
bezbednosti njenih relativno nezavisnih bezbednosnih komponenti (B1,

-4-
B2, ..., Bn), ĉiji se skupovi negde presecaju ali pribliţno aditivno
doprinose porastu ukupne bezbednosti. U idealnom sluĉaju, da je nivo
bezbednosti deterministiĉka veliĉina, ova bi zavisnost bila linearna
funkcija. MeĊutim, ukupna bezbednost je uvek nelinearna funkcija
komponenti bezbednosti, zbog stohastiĉke prirode kombinovanih,
dinamiĉki promenljivih pretnji i faktora rizika (Sl. 1.1).
Nivo
bezbednosti
B1

B3

B2

Komponente
bezbednosti

Sl. 1.1. Nivo ukupne bezbednosti u funkciji komponenti bezbednosti

Ukupna bezbednost sloţenog sistema, na primer sistema e-Uprave na

nivou drţave - Bu, koja obuhvata sve komponente bezbednosti jedne
drţavne uprave (B1,...B8), moţe se izraziti relacijom:

n
Bu= ∑ kj x Bj,
j=1
gde su:
j= 1....n – komponente bezbednosti
kj = k1 .... kn - teţinski faktori uticaja komponenti bezbednosti, koji
razliĉito doprinose porastu nivoa bezbednosnog stanja od j-te
komponente.
Najveći uticaj na ukupnu bezbednost sloţenog sistema, oĉigledno imaju
najosetljivije komponente bezbednosti – drţavna, vojna i ekonomska
bezbednost. U kojoj meri raste informatizacija društva, odnosno razvija
se informatiĉko društvo, u toj meri raste znaĉaj informaciono-
kibernetiĉke bezbednosne komponente, odnosno – bezbednosti
informacija. U tom smislu, uticaj informaciono-kibernetiĉke bezbednosti
u savremenom svetu proţima sve aspekte bezbednosti i ne moţe se
smatrati manje znaĉajnim (tek na 8. mestu) za ukupnu bezbednost, kako
se moţe steći utisak iz gornjeg pristupa.

-5-
1.2. Funkcionalna zavisnost bezbednosti i pretnji
Bezbednost IKT sistema je stanje i uvek je konkretno-situacioni
problem realnog okruţenja. U tom smislu, ne postoji univerzalno,
integralno, pouzdano i nepromenljivo stanje bezbednost IKT sistema.
Potencijalne pretnje (ili agenti pretnji) uzroci su nastanka faktora rizika.
Rizik je procena/mera uticaja pretnje i najopštija kategorija svake analize
bezbednosti sistema. Rizik se moţe definisati kao verovatnoća da će
agent pretnje (izvršilac pretnje) iskoristiti neku ranjivost sistema i
izazvati negativne posledice za sistem i organizaciju u celini. Kako
apsolutna bezbednosti praktiĉno ne postoji, bezbednost IS najbolje se
objašnjava procesom upravljanja rizikom. U realnim uslovima, sa
porastom pretnji (rizika) nivo ukupne bezbednosti IKT sistema
nelinearno opada, zbog stepena neodreĊenosti pojave (realizacije) i
intenziteta uticaja pretnji (Sl. 1.2), [11].
Nivo bezbednosti

B1

B2

B4

B3

B6
B5

Uzroci rizika T (sati)

(Pretnje)

Sl. 1.2. Nivo ukupne bezbednosti IKT sistema u funkciji pretnji

Neka su B1, B2, ...,Bj,..Bn bezbednosna stanja komponenti bezbednosti
IKT sistema, procenjivana u prostoru i vremenu. Funkcija nelinearne
zavisnosti komponenti bezbednosti-Bj od stohastiĉki promenljivih pretnji
i rizika-Ri, moţe se pribliţno izraziti relacijom:
n
Bj= ∑ kj x (1/f (Ri)),
j=1
gde su: j= 1....n – komponente bezbednosti
kj = k1 .... kn = teţinski faktori uticaja relevantnih elemenata
bezbednosti (mera uticaja faktora rizika) odgovarajućih
komponenti bezbednost, a

-6-
 Ri= procenjeni ukupni faktori rizika komponenti bezbednosti, i=
1... n.
Definisanje bezbednosnog stanja IKT sistema sa formalnim
matematiĉkim aparatom nije lak zadatak. Relacioni pristup sa
meĊusobnim odnosima relativno nezavisnih skupova ukazuje na teţinu
ovog problema. Neka je ukupna bezbednost IKT sistema predstavljena
skupom mogućih bezbednosnih stanja svih komponenti sistema zaštite
– S, u kojem bezbednosna stanja koja obezbeĎuju pojedinačne
bezbednosne komponente IKT sistema-si, zavise od vrste, intenziteta i
verovatnoće napada i uticaja kombinovanih, dinamiĉki promenljivih
pretnji na iskoristive ranjivosti sistema.
Kako okruţenje IKT sistema unosi elemenat neodreĎenosti u metriku
nivoa bezbednosti IKT sistema, neka je trenutno bezbednosno stanje
okruženja sistema (Bso) – v, elemenat skupa svih mogućih
bezbednosnih stanja okruženja sistema Bso – V, moţe se definisati kao
funkcija tri varijable, [7]:
V= f(S, A, F)
gde je:
S- skup mogućih bezbednosnih stanja svih komponenti bezbednosti
sistema-si,, u kojem je identifikovan i definisan rizik i implementiran neki
skup kontrola sistema zaštite (upravljačkih, operativnih, tehničkih) koje
smanjuju faktore rizika na prihvatljiv nivo;
A - skup svih raspoloţivih, novih upravljačkih i organizacionih kontrola
zaštite - ai, koje pomeraju sistem iz jednog u drugo bezbednosno stanje;
F - skup svih tehničkih kontrola (mehanizama, protokola) zaštite
komponenti sistema zaštite - fi, koje su implementirane u specifiĉnim
komponentama zaštite IKT sistema - si, na tekućem nivou bezbednosnog
stanja sa faktorom rizika na prihvatljivom nivou.

Zadatak specijalista zaštite je da definiše parove (fi,, Vj), koji ĉine

moguće bezbednosno stanje specifiĉne komponente zaštite IKT sistema
(si), relevantno i prihvatljivo za organizaciju, a postignuto primenom
specifiĉnih faktora zaštite u specifiĉnom bezbednosnom okruţenju, što se
moţe izraziti relacijom: (si, { fi,, Vj, j=1,n }).

Održavanje stanja bezbednosti IKT sistema u nebezbednom okruţenju,

sa aspekta zaštite treba da bude stabilan proces. U praksi zaštite, to se

-7-
stanje odrţava na prihvatljivom nivou rizika sa implementiranim
bezbednosnim komponentama (komponentama sistema zaštite) za zaštitu
podataka i informacija. Stabilno odrţavanje stanja bezbednosti IKT
sistema na ţeljenom i kontrolisanom nivou rizika, potrebno je iz više
znaĉajnih razloga:
 presudnog znaĉaja zaštite poverljivosti, integriteta i raspoloţivost
podataka i informacija, kao najvrednijih objekata IKT sistema, za
poslovni ugled, konkurentnost, rentabilno poslovanje, pravnu
sigurnost i usaglašenost sa zakonima i standardima;
 porasta sve savršenijih malicioznih napada iz širokog spektra pretnji,
koje prate ekspanziju i tehniĉko usloţnjavanje IKT sistema;
 povećavanja ranjivosti objekata IKT sistema sa porastom njihove
kompleksnosti -vrednosti, umreţavanja i broja korisnika zajedniĉih
informacionih resursa;
 teţe realizacije kontrolisanog pristupa i manje efikasnosti i
efektivnosti nekoherentnih kontrola zaštite u kompleksnim visoko
distribuiranim i umreţenim sistemima;
 ograničene bezbednosti IKT sistema koju obezbeĎuju tehničke
kontrole zaštite, pa se u sistem zaštite moraju uvoditi odgovarajući
upravljaĉki i operativni (proceduralni) mehanizmi zaštite, ĉime se svi
zaposleni ĉine odgovornim za bezbednost IKT sistema (koji po svojoj
prirodi nisu ni projektovani da bi se štitili) i
 zbog efikasnijeg, efektivnijeg i rentabilnijeg upravljanja sistemom
zaštite, koje poĉinje se definisanjem i uvoĊenjem okvira za
upravljanje (upravljaĉke, operativne i tehniĉke kontrole zaštite) u fazi
projektovanja i razvoja IS i sistema zaštite za sve faze ţivotnog
ciklusa sistema.
Stabilno odrţavanje stanja bezbednosti IKT sistema na odreĊenom
bezbednosnom nivou obezbeĊuje implementirani sistem zaštite.
Metodologije za razvoj sistema zaštite brojne su i fleksibilne. U opštem
sluĉaju, konzistentan skup bezbednosnih zahteva i odgovarajućih
tehniĉkih specifikacija za planiranje, projektovanje, implementaciju,
odrţavanje i upravljanje sistemom zaštite, svaka organizacija definiše na
osnovu specifiĉnih potreba i rezultata sledećih razmatranja: zakonskih i
drugih normativnih okvira, standarda zaštite, programa i politika zaštite,
namene IS, okruţenja objekata zaštite, upravljanja rizikom, uvoĊenja
novih aplikacija, reinţenjeringa IS, bitnih kadrovskih promena ili
promena u tehnologijama zaštite.

-8-
2. FAKTORI UTICAJA NA BEZBEDNOSNO STANJE
SAVREMENIH INFORMACIONIH SISTEMA

2.1. Uticaj funkcionalnih zahteva poslovnih sistema

Znaĉaj IS za savremene poslovne sisteme je praktiĉno presudan, a

najbolje ga ilustruje ţivotni ciklus procesa upravljanja i odluĉivanja
(PRILOG I 1A), [15]. Kako je odluĉivanje kritiĉan faktor upravljanja,
automatizacijom (IS) skraćuje se proces odluĉivanja i povećava
efikasnost upravljanja, a menadţerskoj strukturi ostaje više vremena za
druge aktivnosti i povećanje konkurentnosti na trţištu. Otuda kvalitetne
informacije, potrebne za odluĉivanje, postaju najznaĉajniji resursi svake
organizacije i kritiĉni objekti zaštite.
Kvalitet informacija odreĊuje niz atributa (tačnost-vernost,
blagovremenost, aktuelnost, pouzdanost, integritet, objektivnost, tajnost,
raspoloživost i dr.) koji pojedinaĉno mogu biti od relativnog znaĉaja za
razliĉite poslovne sisteme. Treba odrediti skup relativno nezavisnih
atributa kvaliteta informacija koji dovoljno dobro predstavlja kvalitet
informacija. Takav skup ĉine atributi: poverljivost, integritet
(uključujući neporecivost) i raspoloživost informacija. Zato je za
savremene IS bezbednost - stanje koje se obezbeĊuje zaštitom:
poverljivosti, integriteta i raspoloživosti informacija, što su prihvatili
brojni standardi zaštite (ISO/IEC 17799, CC, NIST- National Institute for
Standards and Technologies i dr.).
Znaĉaj bezbednosti poslovnih IS raste sa porastom informatizacije svih
sfera ţivota, pa se ukupna pouzdanost i kvalitet IS ĉesto ilustruje
„trouglom stabilnosti― sistema: hardver, softver, bezbednost. Sa aspekta
kvaliteta informacija, zahtevi za viši nivo bezbednosti savremenih IS
(BIS) proporcionalni su značaju (vrednosti) informacija – Ai koje
sistemi obraĊuju, skladište i/ili prenose i izloženosti (ranjivosti)
informacija–Vi u Internet okruţenju. Ako se nivoi znaĉaja i izloţenosti
ponderišu sa teţinskim faktorima 1 (najniţi)-10 (najviši), moţe se
odrediti pribliţan1 nivo informacione bezbednosti sistema u relativnim
jedinicama od 0-1 ili procentima (1-100%) iz relacije, [15]:
BIS = (Ai x Vi)/100

1
Detaljnija analiza faktora koji utiču na ukupan rizik i bezbednost IS data je u
poglavlju Upravljanje rizikom.

-9-
Primer: Ai=8, Vi=4, biće BIS = (Ai x Vi)/100= 0, 32 ili 32%.

MeĊutim, u pristupu problematici bezbednosti i zaštite informacija,

vaţno je shvatiti da je vrednost informacija funkcija vremena -
informacija znaĉajna danas, ne mora biti znaĉajna i sutra, što presudno
utiĉe na naĉin na koji treba štititi informacije u IKT i Internet okruţenju.
Informacije koje organizaciji obezbeĊuju komparativnu prednost za duţi
vremenski period, treba štititi jakim mehanizmima zaštite (npr.
kriptološkim, sa dovoljnom duţinom kljuĉeva i algoritmima otpornim na
proboj). Otuda postoji potreba za razvoj metoda analize rizika,
kompatibilnih sa vremenskim okvirima i dinamikom savremenog e-
poslovanja. Menadţeri za upravljanje sistemom zaštite informacija
moraju obezbediti kompleksno okruţenje brţe i sa upotrebom manjih
resursa, usmeravajući ravnomerno paţnju na kratkoroĉne (taktičke) i
dugoroĉne (strateške) planove, bezbednosne zahteve i ciljeve zaštite.
Strateški plan zaštite po svojoj prirodi obezbeĊuje stabilnije i zrelije
procese zaštite, jer inherentno angaţuje punu podršku menadţerske
strukture i svih resursa organizacije. Kratkoročni procesi obezbeĊuju
brze odgovore na dinamiĉki promenljive pretnje i glavne faktore rizika,
brze promene poslovnih zahteva i razvoj tehnologija.

2.2. Uticaj organizacione strukture

Ĉeste promene organizacione strukture savremenih poslovnih

sistema pod uticajem brojnih ekonomskih i tehnoloških faktora, direktno
utiĉu na zaštitu informacija. Osnovni problem je kako obezbediti
specijaliste zaštite sa potrebnim znanjima i veštinama. Poslovni
menadţeri igraju znaĉajnu ulogu u procesu zaštite informacija, pošto
najbolje poznaju poslovne procese i identifikuju faktore bezbednosnog
IKT rizika u širem kontekstu poslovanja i donose odluke u procesu
upravljanja rizikom. Pored toga, odgovorni su za kljuĉne aktivnosti u
oblasti zaštite, kao što su autorizacija prava pristupa aplikacijama i
podacima, akreditacija i sertifikacija sistema zaštite i drugo, za šta je
neophodno da poseduju odgovarajuća znanja i iskustva, koja se ĉestim
kadrovskim izmenama teško mogu obezbediti, [13].

Posebno su znaĉajne promene prava pristupa zbog promene radnih mesta

koje zahtevaju brzo ukidanje starog naloga i otvaranje novog korisniĉkog
naloga sa novim pravima pristupa. Koherentan pristup ovim pitanjima
zahteva kombinovanu primenu upravljaĉkih i organizacionih procedura i

- 10 -
tehniĉkih mehanizama i protokola zaštite, sa kvalitetnim programom
obuke i razvoja svesti o potrebi zaštite.

2.3. Uticaj razvoja IK tehnologije

Razvoj IK tehnologije poslednjih 20 godina, sa automatizacijom

poslova pomera se na razvoj programa za upravljanje kompleksnim
upravljaĉkim i inţenjerskim procesima. U toku je razvoj i implementacija
programa za automatizaciju administrativnih poslova u sistemima e-
Uprave u većini zemalja u svetu. MeĊutim, administrativne poslove koji
se odnose na bezbednost IKT sistema verovatno nikada neće biti moguće
potpuno automatizovati, zato što ljudski um još uvek adekvatnije reaguje
na dinamiĉki promenljive pretnje od bilo kojeg ekspertskog sistema sa
elementima veštaĉke inteligencije, pa intervencija ĉoveka u sistemu
zaštite ostaje nezamenljiv i kritiĉan faktor.

Praksa potvrĊuje da i tehnologije zaštite slede tipiĉan ţivotni ciklus IKT

sistema, s tim da organizacije više ulaţu u IKT sisteme koji neposredno
povećavaju vrednosti poslovanja, nego u sistem zaštite. Zato se u praksi
tehnologija zaštite najĉešće uvodi pri kraju ţivotnog ciklusa IKT sistema,
kada se povećava rizik zbog uvoĊenja nove generacije IKT sistema, a
prihvatljivi nivo zaštite IKT sistema ĉesto postiţe primenom univerzalnih
(kompenzujućih) kontrola zaštite kao što su barijere (Firewalls) i
antivirusni programi, ili povećanom primenom proceduralnih
mehanizama zaštite.

Na tehniĉkom nivou, kompleksnost savremenih, heterogenih (sa

razliĉitim platformama), visoko distribuiranih IKT sistema OSI modela
arhitekture, glavni je problem za planiranje arhitekture sistema zaštite,
zbog teškoća identifikovanja i korekcije ranjivosti u takvoj arhitekturi.

- 11 -
2.4. Uticaj ograniĉenog znaĉaja politike zaštite

Brz razvoj IK tehnologije utiĉe i na razvoj alata (mehanizama i

protokola) zaštite, kao i raznih tehnologija koje podrţavaju procese
zaštite, kao što su:

 Kriptografske tehnike, dostupne u poslednjih 10 godina širokom

krugu korisnika;
 Tehnologija višeslojne mrežne zaštite, u poslednjoj deceniji
razvijene su od host barijera do sofisticiranih mreţnih kapija
(Gateway) sa komercijalno dostupnim programima koji
kombinuju razliĉite tipove barijera, detektora za upade u sistem
(IDS-Intrusion Detection Systems) i sistema za monitoring zaštite
(skenera), a centralno upravljanih sa zaštićene radne stanice preko
zaštićenih veza;
 Brojni proaktivni bezbednosni alati za raĉunarske sisteme i
raĉunarske mreţe, kao što su skeneri ranjivosti, IDS/IPS-Intrusion
Protection System, sistemi za kriptozaštitu datoteka, skeneri
sadrţaja, web filteri i dr.;
 Programi koji obezbeĊuju servise zaštite na heterogenim
platformama.

Naţalost, procesi zaštite koji treba da obezbede punu prednost ovih alata
nisu dovoljno razvijeni, stabilni i zreli i prepreka su daljeg poboljšanja
oblasti zaštite. U većini organizacija procesi zaštite su, u suštini,
aksiomatski. Naime, odluke se donose uglavnom na bazi zahteva
predefinisanih politika zaštite i procene izloţenosti faktorima rizika na
bazi statiĉkih kontrolnih okvira (standarda za upravljanje zaštitom,
operativnih uputstava i tehniĉkih kontrola zaštite). Ovakav pristup je
sasvim dobar za donošenje strategijskih odluka, ali nije od velike pomoći
za rešavanje dnevnih (taktiĉkih) problema zaštite. Osim toga, da bi se
maksimalno iskoristile funkcionalnosti savremenih alata za zaštitu, vaţno
je razumeti dinamiĉku promenljivost pretnji, razvijati i reagovati na
scenarije pretnji koji se mogu brzo menjati, što zahteva proaktivni
pristup oblasti zaštite, kao i obezbeĊenje realnijeg okvira kontrola zaštite
za arhitekturu savremenih IKT sistema.

- 12 -
Relevantni standard zaštite (ISO/IEC 17799) priznaje sva ograniĉenja
sistema zaštite, projektovanog na bazi predefinisanih politika zaštite i
sugeriše uvoĊenje metoda procene rizika da bi se izabrale odgovarajuće
kontrole zaštite za realne faktore rizika. Tako je i Bazelski komitet za
superviziju bankarskih sistema preporuĉio da sve finansijske institucije
do kraja 2006 godine obavezno uvedu procenu operativnog rizika u
proraĉun kapitala, što zahteva kvantitativno merenje rizika, za što još ne
postoje odgovarajuća metodologije, niti alati u oblasti zaštite informacija,
[4].

Dakle, da bi se obezbedio optimalan odgovor na bezbednosne rizike u

IKT sistemima, Kako je sistem zaštite prevashodno u funkciji pouzdanog
funkcionisanja IKT sistema i izvršavanja poslovnih ciljeva i misije
organizacije, procesi zaštite moraju veću paţnju usmeriti na poslovne
zahteve i operativni rizik, umesto na sam kontrolni okvir (upravljaĉke,
operativne, tehniĉke kontrole zaštite) kojeg standard nudi. Ovaj pristup
podrazumeva da se procena rizika uzima kao primarni alat za donošenje
odluka, što ne znaĉi da politike zaštite i standardni kontrolni okvir nisu
vaţni; naprotiv, treba ih redovno koristiti, ali samo ĉešće kontrolisati
njihovu relevantnost u realnom kontekstu na bazi procene rizika.

2.5. Uticaj obuke i razvoja svesti o potrebi zaštite

Kompleksnost IKT sistema i tehnologija zaštite zahtevaju visoko

specijalizovana i aktuelna znanja. U odreĊenoj meri, Nedostatak svesti o
potrebi zaštite, znanja i veština mogu se, u odreĊenoj meri, nadoknaditi
razvojem i implementacijom kvalitetnih programa obuke. Veći problem
je nedostatak svesti menadţera o potrebi procene i kontrole rizika, koji
obiĉno ne shvataju ukupnu izloţenost riziku i ĉešće su opredeljuju za
tehnologiju zaštite bez procene rizika, kao i krajnih korisnika koji
nedovoljno shvataju potrebu kontrole i posledice uticaja faktora rizika na
dnevne aktivnosti. Postoji potreba za uvoĊenjem procesa za upravljanje
operativnim rizikom u organizaciji, koji efektivno pokriva sve aspekte
rizika u IKT sistemu, ukljuĉujući i faktore bezbednosnog rizika za sistem
zaštite. U tom smislu, regularni programi obuke i razvoja svesti o potrebi
zaštite mogu pomoći da izvršni menadţeri shvate i uspešno prenesu
zahteve politike zaštite sa nivoa programa u metode koje obezbeĊuju
upravljanje rizikom na taktiĉnom nivou.

- 13 -
TakoĊe, forsiranje primene tehniĉkih rešenja zaštite, moţe stvoriti iluzija
da se rizik uspešno kontroliše i da bezbednost uglavnom zavisi od
primene sve novijih i novijih alata. Iako u oblasti zaštite dominiraju
tehnološka pitanja (što pokazuju dostupne reference), sa aspekta ukupne
bezbednosti IKT sistema, treba izbegavati projektovanje arhitekture
sistema zaštite samo na bazi tehnologije i standarda najbolje prakse
zaštite. Racionalan pristup projektovanju arhitekture sistema zaštite
obezbeĊuje samo razumevanje realnog rizika, njegovog relativnog
znaĉaja za organizaciju i kako odreĊene tehniĉke kontrole i druge mere
zaštite mogu smanjiti taj rizik.

2.6. Faktori uticaja na praksu zaštite IKT sistema

Sa aspekta operativne prakse zaštite, zasnovane na opšte

prihvaćenim principima zaštite, zrelim i stabilnim procesima zaštite u
savremenom IKT okruţenju, na razvoj programa i sistema zaštite glavni
uticaj imaju faktori kao što su: kompleksnost, skalabilnost, poverljivost i
privatnost.

Kompleksnost IKT sistema je glavni problem zato što je potrebno

duboko razumevanje principa funkcionisanja sistema, da bi se
implementirala zaštita. Napadaĉi uvek nastoje da iskoriste najslabiju
taĉku sistema, a ozbiljne ranjivosti mogu se kriti u skrivenim funkcijama
ili opcijama konfiguracije. Kompleksnost savremenih arhitektura IKT
sistema predstavlja ozbiljnu prepreku za postizanje koherentnog sistema
zaštite u celom IKT sistemu organizacije zbog teškog usklaĊivanja
servisa zaštite na razliĉitim platformama, nedovoljnog broja univerzalnih
alata zaštite za razliĉite platforme i teške analize i nepoznavanje
potencijalnih ranjivosti interfejsa izmeĊu razliĉiti platformi.

Zahtev za skalabilnost raste uporedo sa porastom kompleksnosti,

distribuiranosti i umreţavanja IKT sistema. U savremenom IKT
okruţenju vaţno je traţiti rešenja zaštite sa aspekta arhitekture i
topologije mreţe IKT sistema, uz analizu svakog sistema (platforme) u
realnom kontekstu. Pristup sa aspekta arhitekture i topologije automatski
zahteva analizu atributa skalabilnosti i mogućnosti integracije, a ovo su
upravo aspekti koji se ĉesto ne razmatraju u procesu analize nekog IKT
sistema.

- 14 -
Poverljivost i privatnost su dva kljuĉna pitanja koja su dramatiĉno izbila
na površinu, sa povećavanjem broja umreţenih aplikacija i primene
Internet tehnologija. Korisnik se autentifikuje sistemu kojem pristupa sa
korisniĉkim imenom i pasvordom. Kada se završi proces autentifikacije
(verifikacije identiteta) sistem nameće logiĉku kontrolu pristupa (LAC),
nametanjem i odrţavanjem jedinstvenog skupa pravila koja definišu koji
korisnici su ovlašćeni (autorizovani) da pristupe kojim odreĎenim
objektima IKT sistema. Sam proces LAC nije se znaĉajno izmenio od
vremena mainframe sistema, dok je proces autentifikacije postao tehniĉki
najkompleksnija oblast zaštite savremenih IKT sistema u Internet
okruţenju, zbog sve veće razmene informacija izmeĊu nepoznatih i
nepoverljivih korisnika.

Savremeno poslovanje zahteva modele autentifikacije koji mogu rešiti

istovremeno probleme uzajamnog poverenja i zaštite privatnosti
korisnika. Tako proces autentifikacije preuzima kompleksan problem
prenosa poverenja u IKT okruženju. Standard za implementaciju
poverenja na Internetu, praktiĉno je postala infrastruktura sa javnim
kljuĉem (PKI-Public Key Infrastructure), u kojoj bezbednosni
kredibilitet korisnika predstavljaju digitalni sertifikati, identifikatori
analogni papirnom liĉnom dokument (pasoš, liĉna karta, vozaĉka
dozvola), koje krajnji korisnici imaju za autentifikaciju. Digitalne
sertifikate izdaje poverljivi provajder zaštite (TTP-Trusted Third Party)
poznat kao sertifikaciono telo - CA (Certificate Authority), u kojeg
veruju svi korisnici u komunikaciji. U principu, poverenje u digitalni
sertifikat danas je gotovo jednako poverenju u bilo koji liĉni dokument,
koji nam omogućavaju da verifikujemo identitet nosioca, ali ne garantuju
da vlasnik identiteta zasluţuje poverenje.

Zahtevi za zaštitom privatnosti i poverljivosti liĉnih i drugih autorskih

informacija i podataka rastu uporedo sa lakoćom sa kojom se elektronske
informacije mogu skladištiti, prenositi, menjati i distribuirati. U većini
zemalja u svetu doneti su zakoni za zaštitu privatnosti liĉnih podataka u
elektronskom okruţenju. Debate se vode o tome šta predstavlja dobru
politiku zaštite privatnosti i kako je nametnuti u web okruţenju. Tehniĉke
mogućnosti presretanja (intercepcije) i hvatanja e-mail poruka,
monitorisanja pristupa Internetu i snimanja telefonskih poziva vrlo su
velike, a komercijalno su dostupni brojni alati. Brojni su zahtevi za
razvoj programa za monitorisanje aktivnosti na kućnim raĉunarima
korisnika i traţenje prisustva alata za ove namene.

- 15 -
Primeri uticaja faktora kompleksnosti, skalabilnosti i alata za
monitorisanje i zaštitu privatnosti dati su u PRILOGU I 1B.

Sasvim je jasno da se zaštita privatnosti i monitorisanje privatnih

informacija i podataka mora kontrolisati. U SAD postoji predlog od 10
glavnih uputstava za zaštitu privatnosti na radnom mestu (Top Ten
Gudelines to Workplace Privacy, 2001.), [16], dok se pristup ovom
problemu bitno razlikuje od zemlje do zemlje. Pitanje zaštite privatnosti
u elektronskom okruţenju postalo je vruća tema pojavom evropskog
sistema za intercepciju (ESHALON), projektovanog da presreće privatne i
poslovne komunikacije širom sveta, što je suprotno sekciji 8 konaĉnog
izveštaja privremenog komiteta evropskog parlamenta u kojem se navodi
da: „Svaki akt koji uključuje intercepciju komunikacija i čak snimanje
podataka od strane obaveštajnih službi za obaveštajne namene,
predstavlja ozbiljno kršenje lične privatnosti―. U tom smislu, oĉekuje se
da pojedinci i organizacije ozbiljno razmatraju korišćenje jake
kriptografske zaštite informacija i podataka na prenosnim putevima.
MeĊutim, porast terorizma u svetu posebno kompjuterskog kriminala
nameće potrebu da se izbalansiraju liĉna prava zaštite privatnosti i
potrebe drţava da imaju pristup svim informacijama i podacima.

Generalno, pored navedenih inherentnih faktora, bezbednost IKT sistema

ugroţavaju brojne pretnje koje mogu doći iz same poverljive RM
(intraneta) i nepoverljivog okruţenja (Interneta), usled sluĉajnih dogaĊaja
(prirodnih dogaĊaja, tehniĉkih i ljudskih grešaka) ili namernih aktivnosti
malicioznih napada neovlašćenih korisnika (hakera i dr.).

- 16 -
3. REZIME

Bezbednost IKT sistema je objektivna mera/ocena stanja rizika

IKT sistema ili stanja sigurnog, pouzdanog i neometanog funkcionisanja
sistema u odnosu na sam sistem ili njegovo okruţenje. Sistem se smatra
bezbednim, ako je zaštićen od uticaja faktora rizika. Sigurnost IKT
sistema u srpskom jeziku je sinonim bezbednosti, subjektivna mera
osećaja sigurnosti (uverenja) korisnika da je sistem bezbedan, a
semantiĉki najbliţe odgovara znaĉenju engleskog termina Assurance
(bezbednosna garancija, ili bezbednosna pouzdanost), koji odraţava
uverenje da je IKT sistem bezbedan. Nivo bezbednosnog stanja odreĊuje
se nivoom preostalog i prihvatljivog rizika, a ukupna bezbednost
sloţenog sistema proporcionalna je skupu bezbednosnih stanja svih
komponenti bezbednosti, koje neravnomerno utiĉu na ukupnu
bezbednost. Najveći uticaj na ukupnu bezbednost sloţenog sistema,
oĉigledno imaju najosetljivije komponente bezbednosti.

Bezbednost IKT sistema uvek je konkretno-situacioni problem stanja

sistema i realnog okruţenja i ne postoji univerzalno, integralno,
pouzdano i nepromenljivo stanje bezbednost IKT sistema. U realnim
uslovima, sa porastom pretnji i faktora rizika nivo ukupne bezbednosti
IKT sistema nelinearno opada, zbog stohastiĉke prirode pretnji.

Sa aspekta zaštite, traţi se odrţavanje stabilnog bezbednosnog stanja IKT

sistema u nebezbednom okruţenju, sa implementiranim bezbednosnim
komponentama sistema zaštite informacija na prihvatljivom nivou rizika.
Kako apsolutna bezbednosti praktiĉno ne postoji, bezbednost IS najbolje
se objašnjava procesom upravljanja rizikom.

Za održavanje stanja bezbednosti IKT sistema, zadatak specijalista

zaštite je da definiše parove (fi,, Vj) - mehanizama i protokola zaštite
bezbednosnih komponenti (fi) i skupa mogućih bezbednosnih stanja
okruţenja sistema (Vj), koji ĉine moguće bezbednosno stanje specifiĉne
komponente bezbednosti IKT sistema (si), relevantnim i prihvatljivim za
organizaciju, a postignuto primenom specifiĉnih faktora zaštite u
specifiĉnom bezbednosnom okruţenju (si, { fi,, Vj, j=1,n }).

Održavanje stanja bezbednosti IKT sistema na ţeljenom i kontrolisanom

nivou rizika, za svaki poslovni sistem potrebno je iz više brojnih i
znaĉajnih razloga, a obezbeĊuje ga implementirani sistem zaštite.

- 17 -
Zahteve za planiranje, projektovanje i implementaciju sistema zaštite,
organizacija definiše na osnovu razmatranja normativnih okvira,
standarda zaštite, programa i politike zaštite, namene IS, promena
okruţenja i procene rizika.

Na bezbednosno stanje savremenih IKT sistema utiĉi brojne grupe vrlo

razliĉitih faktora (realno stanje poslovnih sistema, organizaciona
struktura, razvoj IK tehnologija, ograničenja politika zaštite, svest i
obuka o zaštiti i operativna praksa), a posebno - znaĉaj IS za savremene
poslovne sisteme, koji se najbolje moţe ilustrovati ciklusom procesa
upravljanja i odlučivanja. Ako je odluĉivanje kritiĉan faktor upravljanja,
a ukupno vreme za donošenje odluke bitno smanjuje automatska obrada
informacija u IS, onda kvalitetna informacija za odluĉivanje postaje
najvredniji resurs svake organizacije.

Kvalitet informacija odreĊuje niz atributa (tačnost-vernost,

blagovremenost, aktuelnost, pouzdanost, integritet, objektivnost, tajnost,
raspoloživost i dr.) koji pojedinaĉno mogu biti od relativnog znaĉaja za
razliĉite poslovne sisteme. Treba odrediti skup relativno nezavisnih
atributa kvaliteta informacija koji dovoljno dobro predstavlja kvalitet
informacija. Takav skup ĉine atributi: poverljivost, integritet
(uključujući neporecivost i autentifikaciju) i raspoloživost informacija.
Zato je za savremene IS bezbednost - stanje koje se obezbeĊuje zaštitom:
poverljivosti, integriteta i raspoloživosti informacija, što su prihvatili
brojni standardi zaštite (ISO/IEC 17799, CC, NIST- National Institute for
Standards and Technologies i dr.).

- 18 -
4. KLJUĈNI TERMINI

Bezbednost sistema: (engl. security, rus. безопасность, nem.

sicherheit) objektivna mera ili ocena stanja sistema u odnosu na sam
sistem ili okruţenje; objektivna mera/ocena stanja rizika IKT sistema;
bezbedan sistem je obezbeĊen (zaštićen) od uticaja faktora pretnji.
IKT sistem: sistem informaciono-komunikacionih tehnologija koji
obuhvata integrisani skup ljudi, programa, hardvera, aplikacija,
protokola, komunikacione infrastrukture, procesa i njihovih meĊusobnih
veza, koji izvršavaju zajedniĉku funkciju i zajedno obezbeĊuju kapacitete
za zadovoljavanje nekih potreba organizacije.
Informacija: podaci o ĉinjenicama, saznanjima, procesima i pojavama, o
stanju objekata (svojstava, karakteristika) u nekoj predmetnoj oblasti,
iskorišćena (neophodno) za optimizaciju primenjenih rešenja u procesu
upravljanja datim objektima. Informacija moţe biti dokumentarna (u
pisanoj ili elektronskoj formi), govorna, vizuelna, telekomunikaciona
i.t.d. i moţe biti na razliĉitim nosiocima; skup obraĊenih podataka ĉiji
sadrţaj povećava znanje; opis svojstava nekog entiteta; verovatnoća
mogućeg stanja sistema; obaveštenje; smanjenje neizvesnosti; sadrţaj
poruke; osnovni atribut kljuĉnog koncepta savremenog društva –
upravljanja znanjem
Informacioni objekti IKT sistema : ţeljena informacija (poruka,
obaveštenje, datoteka baze podataka i.t.d.) u ţeljenoj formi prezentacije
(analogna, digitalna, virtuelna, misaona i.t.d.); tehniĉki ili organizacioni
sistem odreĊenog stepena sloţenosti, koji izvršava neki zadatak
procesiranja informacija (obrade, skladištenja, prenosa i.t.d.) informacija.
Taĉka u kojoj informacija ulazi u informacioni objekat naziva se
pristupna taĉka, a u kojoj izlazi za korisniĉku upotrebu naziva se terminal
ili interfejs.
Informacioni sistem (IS): integrisani skup hardvera, softvera, ljudi i
njihovih meĊusobnih veza za obradu, skladištenje i prenos informacija i
podataka; sinonim IKT sistema; kompleksan prostorno distribuiran
sistem koji sadrţi skup lokalnih podsistema (komponenti), raspoloţivih
sistemskih programa i IKT ureĊaja, skup sredstava koji obezbeĊuju
koherentnu interakciju tih podsistema, koji u celini vrši usluge širokom
krugu udaljenih korisnika iz oblasti informacionog obezbeĊenja.
Integritet informacija/sistema: stanje u kojem informacije/sistemi nisu
izmenjeni na neovlašćen naĉin, a obezbeĊena je detekcija bezbednosno
relevantnih dogaĊaja i oporavak sistema.

- 19 -
Kontrola zaštite: konaĉna (krajnja) klasifikacija mehanizama zaštite,
tipiĉno neka funkcija arhitekture sistema zaštite, a odnosi se na tehniĉke
sisteme (tehničke kontrole), operativne (operativne kontrole) i
upravljaĉke (upravljačke kontrole) aktivnosti.
Neporecivost informacija: stanje sistema u kojem stranke u transakciji
ne mogu naknadno poricati izvršene aktivnosti u transakciji ili delovima
transakcije.
Objekti IKT sistema: sve komponente sistema, ureĊaji, sistemski i
aplikativni programi, procedure, protokoli upravljaĉke strukture i.t.d;
mogu biti fizički (raĉunarski sistemi - serveri, radne stanice, ruteri sviĉevi
i.t.d.), logički (sistemski programi, aplikativni programi, softverski alati)
i korisnički (podaci, informacije, aplikacije) objekti IKT sistema koji
procesiraju, skladište ili prenose digitalne podatke i informacije.
Obrada informacija u IKT sistemu: bilo koji skup operacija (prijem,
skupljanje, pohranjivanje, transformacija, predaja, prenos i.t.d.), koji se
izvršava nad informacijama pomoću objekata IKT sistema.
Poslovni IS: IS koji povezuje upravljaĉke i izvršne funkcije, formira
informacije na osnovu poslovnih podataka i stavlja ih na raspolaganje
podsistemu za upravljanje i donosiocima odluka; informacije su kljuĉni
resurs svakog poslovnog sistema.
Pouzdanost (funkcionalna, tehniĉka, operativna): korektno
funkcionisanje komponenti, ureĊaja, podsistema i sistema u operativnom
okruţenju, sa performansama parametara u propisanim granicama.
Poverljivost informacija/sistema: stanje u kojem informacije/sistemi
nisu dostupni neovlašćenim korisnicima.
Raspoloţivost informacija/sistema: stanje u kojem se informacijama/
sistemima moţe pristupati po potrebi.
Sigurnost sistema: (eng. assurance) mera subjektivnog osećaja ili
ubeĊenja da je sistem bezbedan, da mu ne preti nikakva opasnost jer je
zaštićen (osiguran) i veruje se da je mala verovatnoća negativnih uticaja
faktora rizika; u semantiĉkom znaĉenju sinonim bezbednosti sistema.
Sistem: integrisani skup ljudi, proizvoda i procesa i njihovih meĊusobnih
odnosa, koji obezbeĊuje kapacitete (sposobnost) za zadovoljavanje neke
potrebe ili cilja; skup stvari ili delova koji formiraju kompleks ili
jedinstvenu celinu; skup komponenti organizovanih da ispune specifiĉnu
funkciju ili set funkcija; interaktivna kombinacija elemenata, koja se
posmatra u meĊusobnom odnosu sa funkcijama.
Zaštita informacija: specifiĉno se primarno odnosi na zaštitu
informacija i podataka, kao najvrednijih objekata IKT sistema i

- 20 -
organizacije u celini; sekundarno - podrazumeva zaštitu ostalih fiziĉkih i
logiĉkih objekata IKT sistema (servisa, aplikacija, računarskog
sistema, računarske mreže, IKT sistema) u cilju zaštite informacija i
podataka; svi termini koriste se ravnopravno, a iz konteksta se zakljuĉuju
šta je primarni objekat zaštite.
Zaštita objekata IKT sistema: ostvaruje se uvoĊenjem i
implementacijom skupa pogodnih kontrola sistema zaštite koji
obezbeĊuje objekte IKT sistema od posledica neţeljenih uticaja i
ugroţavanja propisanog funkcionisanja; podrazumeva kompleksan sistem
mera, metoda, tehnika i alata namenjenih za zaštitu: poverljivosti,
integriteta i raspoloživosti podataka i informacija, aplikacija, servisa i
sistema od potencijalnih agenata pretnji, ĉiji je cilj ugroţavanje
navedenih svojstava objekata sistema, iskorišćavanjem odreĊenih
upravljaĉkih, operativnih i tehniĉkih ranjivosti sistema.
Zaštita: stanje ili kompatibilna mera bezbednosnog stanja (zaštićenosti,
obezbeĊenosti) sistema na nekom bezbednosnom nivou; „druga strana
medalje― koja se zove bezbednost.

- 21 -
5. LITERATURA

1. American Bar Association, Section of Science &Technology

Law, Privacy & Computer Crime Committee, International
Strategy for Cyberspace Security,
www.abanet.org/abapubs/books/cybercrime/, 2003
2. Australian Communications-Electronic Security Instruction 33
(ACSI 33), www.acsi.com , 2002.
3. Bjork Fredrik, Security Scandinavian Style-Interpreting the
practice of managing information security in organizations,
Stockholm University, Rozal Institute of Technology, 2001.
4. COBIT, Cobit-Control Objectives for Information and Related
technologies, http://www.ITgovernance.org and
http://www.isaca.org, 2000.
5. Domarev V.V.,Защита информации и безопасность
компьютерных систем, http://www.security.ukrnet.net/. 1997.
6. Dr. Rayford B. Vaughn, Jr, A practical approach to sufficient
INFOSEC, Mississippi State University, Department of Computer
Science, vaughn@cs.msstate.edu, 2002.
7. Glenn Fourie, The evolution of the information Security mindset:
a hypothesis of Stages of individual and enterprise Security
maturation, www.sans.com, May 8, 2002
8. Grance T., Hash J., Stevens M., Security Considerations in the
Information System Development Life Cycle , NIST SP 800-64,
http://csrc.nist.gov/publications/nistpubs/800-64/sp800-64.pdf,
juni 2004.
9. http://www.cve.mitre.org/
10. ISO/IEC 17799:2000, Information Technology – Code of practice
for information security management, http://www.iso.org, 2003.
11. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
12. NIST SP 800-12, An introduction to computer Security- The NIST
Handbook, , http://csrc.nist.gov/publications/nistpubs/800-
12/sp800-12.pdf, avgust 2003.
13. Purser S., A practical guide to managing information security,
Artech House, Boston, London, www.artechhouse.com, 2005.
14. RFC 2196, Site Security handbook,
http://www.ietf.org/rfc/rfc2196.txt, 1997.

- 22 -
15. Rodić B., ĐorĊević G., Da li ste sigurni da ste bezbedni,
Produktivnost AD, Beograd, 2004.
16. Sigvartsen, A.L., Guidelines to Workplace Privacy,
http://www.infosatellite.com/news/2001/10/a311001workplace_
security.html, 2003.
17. Stoneburner G., Hayden C. and Feringa A., Engineering
Principles for Information Technology Security (A Baseline for
Achieving Security), NIST SP 800-27,
http://csrc.nist.gov/publications/nistpubs/800-12/sp800-12.pdf,
2004.
18. The Canadian Handbook on Information Technology (IT)
Security, www.canada.gov.itsec.com, 1999.

- 23 -
3. MODELI I OKVIRI ZA RAZVOJ SISTEMA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja razumećete:

- značaj metodološkog okvira za razvoj sistema zaštite

- opštu metodologiju za razvoj programa i sistema zaštite
- vrste modelovanja procesa, komponenti i sistema zaštite
- metodologiju vektora zaštite (S-vektora)
- strukturni i objektno orijentisani model sistema zaštite

Porast pretnji i glavne promene okruţenja, tehnologija IS ili

tehnologija zaštite dovode do degradacije bezbednosnog stanja. Sistem
zaštite odrţava bezbednosno stanje IKT sistema na odgovarajućem
(ţeljenom) nivou zaštićenosti. Smisao uvoĊenja i odrţavanja sistema
zaštite je podizanje bezbednosnog stanja sistema na viši nivo i
odrţavanje tog stanja.

Za razvoj i implementaciju program zaštite treba definisati, razviti i

implementirati ĉetiri kljuĉna koncepta sistema zaštite: metodologiju,
tehnologiju, operativnu praksu i odgovornosti. Klasiĉne metodologije za
razvoj IKT sistema za ţivotni ciklus sistema (SDLC-System Development
Life Cycle) preuzeta je kao formalna metodologija i za razvoj sistema
zaštite (NIST). MeĊutim, istraţivanja su potvrdila da ova, ili bilo koja
standardizovana metodologija nije najpogodnija za sve, ĉak ni za većinu
projekata razvoja savremenih IKT sistema za e-poslovanje i njihovih
(pod)sistema zaštite.

Metodologije i okviri u oblasti zaštite koriste se u kontekstu organizacije

na osnovu internih standarda, ili šire prihvaćenih industrijskih standarda.
Oba konteksta su jednako znaĉajna. Metodologije i okviri grupišu se
zajedno, najĉešće kao upravljačke kontrole, pošto se obe koriste da
dodaju strukturu procesima zaštite.

U praksi zaštite malo je verovatno da će se primena metodologije i okvira

podudariti sa bilo kojom poznatom metodologijom i okvirom. Projektant
moţe izabrati model metodologije koji najviše odgovara, a korišćenjem
okvira, moţe identifikovati nedostatke i planirati unapred njihovu
kompenzaciju. Ako ne postoji ni jedna jedinstvena metodologija koja
evidentno najbolje odgovara, projektant može kreirati sopstvenu

- 24 -
metodologiju, kombinujući razliĉite aspekte metodologija koje
najefektivnije obuhvataju sve varijable.

Savremeni sistemi za e-poslovanje i (pod)sistemi njihove zaštite razlikuju

se od klasiĉnih IS po brzini promena okruţenja i tehnologija i zahtevaju
nove pristupe procesima projektovanja i razvoja. Metodologije za razvoj
tradicionalnih sistema, (model SDLC, Vodopada do brzo-reagujućih),
razvijane su za razliĉita okruţenja i ne mogu se lako preneti u web
okruţenje sa enormnim porastom rizika. Za zaštitu web aplikacija od
presudnog znaĉaja je pouzdanije merenje i odrţavanje kvaliteta sistema
zaštite web aplikacija. Za zaštitu web aplikacija i IS za e-poslovanje,
razvijena je merljiva metodologija vektora zaštite (S-vektora),
kombinacijom tri standarda zaštite: ISO 15408, ISO/IEC 17799 i
ISO/IEC 21827.

- 25 -
1. METODOLOŠKI OKVIR ZA RAZVOJ SISTEMA ZAŠTITE

Sistem zaštite odrţava bezbednosno stanje IKT sistema-BS1 u

vremenu-To na ţeljenom nivou zaštićenosti (Sl. 1.1). Porast pretnji i
glavne promene okruţenja, tehnologija IS i zaštite dovode do degradacije
bezbednosnog stanja. Smisao uvoĊenja sistema zaštite je podizanje
bezbednosnog stanja sistema na viši nivo. Pomeranje bezbednosnog
stanja IKT sistema i okruţenja (BS1) iz taĉke To, na viši nivo
bezbednosnog stanja (BS2) u taĉki T1, vrši se uvoĊenjem i
implementacijom novog skupa pogodnih (poboljšanih) kontrola zaštite,
koji efektivno i efikasno obezbeĊuje objekte IKT sistema od posledica
neţeljenih uticaja pretnji i ugroţavanja propisanog funkcionisanja.

Strategija (vizija, inicijative, indikatori progresa

akcioni plan)
Metodologija
Tehnologija
IKT IKT
sistem sistem
Praksa
Odgovornosti

T1, BS2
To, BS1

Sl. 1.1. Strategija bezbednosti IKT sistema u funkciji sistema zaštite

Strategija zaštite obezbeĊuje okvir za razvoj sistema zaštite za dugoroĉne

bezbednosne ciljeve, pošto sadrţi konsolidovanu viziju tekućeg i
ţeljenog bezbednosnog stanja sistema. Sam koncept strategije zaštite
sadrţi (Sl. 1.1): presek stanja sistema zaštite, viziju za dostizanje ţeljenog
bezbednosnog stanja, inicijative za dostizanje tog stanja, sistem
indikatora za praćenje progresa i akcioni plan za izvršavanje strateškog
cilja. Za razvoj i implementaciju programa i strateškog plana zaštite treba
definisati, razviti i implementirati ĉetiri kljuĉna koncepta sistema zaštite:
metodologiju, tehnologiju, operativnu praksu i odgovornosti u zaštiti IKT
sistema. U Tabeli 1.1. prikazani su ovi kljuĉni koncepti sa primerima
realizacije.

- 26 -
 Koncept Primeri realizacije
Principi: GAISP (OECD, NIST) principi zaštite (sveobuhvatnost, integralnost,
modularnost, skalabilnost, ....)
Metodologija Koncepti: najĉešće modeli IS, procesa, komponenti i arhitekture sistema zaštite, reaktivni
sistem zaštite, proaktivni sistem zaštite, kontrolni okvir i dr.
Alati, tehnike (metodi): kvantitativni, kvalitativni metodi; hardverski, softverski alati;
manuelne, poluautomatske i automatske tehnike,
Razvoj procesa: primena sistemskog inţenjerstva, projektno-procesni pristup; plan zaštite
– program, politike, procedure
Tehničke kontrole (alati-hardversko/softverski mehanizmi i protokoli) za:
Tehnologija identifikaciju/autentifikaciju, kontrolu fiziĉkog i logiĉkog pristupa raĉunarima, RM i
drugim objektima IKT sistema, kriptozaštita, detekcija/spreĉavanje upada u sistem
(IDS/IPS), kontrola saobraćaja (skeneri) i dr.
Praksa Operativne kontrole: sprovoĊenje aktivnosti i procedura zaštite u cilju maksimizacije
zaštite upravljaĉke, funkcionalne i operativne efikasnosti IKT sistema
Odgovornost Upravljačke kontrole: pripisivanje odgovornosti za zaštitu menadţerskoj strukturi i svim
zaposlenim u cilju minimizacije zakonske odgovornosti i legalnih posledica i
maksimizacije prakse zaštite

Tabela 2.1. Kljuĉni koncepti za razvoj sistema zaštite

Metodologije i okviri u oblasti zaštite koriste se nekoj organizaciji u dva

konteksta: na osnovu internih standarda i/ili na osnovu opšte prihvaćenih
industrijskih standarda. Oba konteksta su jednako znaĉajna. Metodologije
i okviri grupišu se zajedno, najĉešće kao upravljačke kontrole, pošto se
obe koriste da dodaju strukturu procesima zaštite [23].

PRIMERI metodologija: CRAMM za analizu rizika, CC-zajedniĉki

kriterijumi za evaluaciju proizvoda zaštite, COBIT-za nadzor i kontrolu u
sistemu zaštite, ISO/IEC 17799 - za upravljanje zaštitom, metodologija
vektora zaštite i.t.d.
PRIMERI okvira u oblasti zaštite su: ISO/IEC 21827 (SSE CMM-System
Security Engineering Capability Maturity Model), model i metod
sazrevanja procesa zaštite – procesni pristup za definisanje, izbor i razvoj
programa zaštite; ISO/IEC 17799 II deo - okvir za izbor kontrola zaštite i
nametanje politika zaštite.

Kada neka organizacija primeni metodološki okvir na odreĊeni projekat

zaštite, razmatrajući sve organizacione, projektne i timske varijable, malo
je verovatno da će se okvir perfektno podudariti sa bilo kojom poznatom
metodologijom. U tom sluĉaju projektant moţe izabrati model
metodologije koji najviše odgovara i gde se najlakše mogu uoĉiti
ograniĉenja modela kada se primeni na projekat. Korišćenjem okvira,
projektant moţe identifikovati nedostatke i planirati unapred njihovu
kompenzaciju. Alternativno, kada ne postoji ni jedna jedinstvena

- 27 -
metodologija koja evidentno najbolje odgovara, projektant može kreirati
sopstvenu metodologiju, kombinujući razliĉite aspekte onih metodologija
koje najefektivnije obuhvataju sve konkretne organizacione, projektne i
timske varijable.

Kljuĉni faktori koji razlikuju savremene sisteme za e-poslovanje i

sisteme njihove zaštite od klasiĉnih IKT sistema i zahtevaju nove
pristupe procesima projektovanja i razvoja, ukljuĉuju brţe promene
okruţenja, brţi razvoj tehnologija, veću paţnju na razvoj interfejsa
ĉovek-mašina za automatizaciju upravljanja i veću potrebu za timskim
radom kreativnih struĉnjaka i specijalista u razvojnim timovima.
Metodologije za razvoj tradicionalnih sistema, poĉevši od modela SDLC
i Vodopada do najnovijih brzo-reagujućih modela, razvijane su za veoma
razliĉita okruţenja (kulturološka, tehnološka i bezbednosna) i ne mogu se
lako preneti i transplatirati u novo web okruţenje sa enormnim porastom
faktora bezbednosnog rizika. Pregled tradicionalnih metodologija i
modela za razvoj IKT sistema dat je u PRILOGU I 3A. Zato je za zaštitu
web aplikacija od presudnog znaĉaja pouzdanije merenje i odrţavanje
sistema kvaliteta zaštite web aplikacija. Kako metodologija za razvoj
IKT sistema nije svrha sama sebi, predloţeno je da se za razvoj sistema
za e-poslovanje primeni lakša verzija kombinacije tradicionalnih
metodologija. Na isti naĉin, za merljivu metodologiju sistema zaštite web
aplikacija i IS za e-poslovanje, predloţena je kombinacija karakteristika
dva poznata standarda (ISO/IEC 17799 i ISO/IEC 21827-SSE CMM),
poznata kao metodologija vektora zaštite (S-vektora), [26].

Odgovarajuća metodologija razvija se i primenjuje se za razvoj procesa,

kontrola zaštite, infrastrukture, arhitekture, komponenti ili sistema IKT
zaštite. Svaka metodologija u potpunosti je odreĊena, definisanjem:
principa, koncepata (modela), metoda upotrebe (tehnologije-tehnika i
alata) i toka razvoja procesa (redosleda izvršavanja postupaka ili
procedura primene alata).

Principi su, prema teoriji sistemskog inţenjerstva (SE), aksiomatske,

fundamentalne istine, ili zakonitosti koje su relativno nepromenljive, a
uzimaju se kao osnova za izvršavanje racionalne i razumne aktivnosti u
procesu realizacije nekog koncepta. Na primer, principi elementarne
logike su – analiza, sinteza, dedukcija, apstrakcija i dr. U oblasti zaštite,
procesi upravljanja zaštitom, razvoja i upravljanja programom i
politikama zaštite, zasnivaju se na sistemskim, opšte prihvaćenim i

- 28 -
funkcionalnim principima zaštite (GAISP– Generaly Accepted
Information Security Principles), [9], koji su sastavni elementi standarda,
uputstava, projekata i prakse zaštite i pomoću kojih se upravljaju,
zaštićuju i distribuiraju objekti sistema, ukljuĉujući osetljive podatke i
informacije (ISO/IEE 13335).

Koncept zaštite, najĉešće model, pribliţna je aproksimacija realnog

sistema zaštite, kojim se definiše razumevanje osnovnih funkcionalnih
elemenata sistema, komponenti ili procesa i kontrola zaštite, ili
strukturnih elemenata infrastrukture i arhitekture IS, ili komponenti
sistema, podsistema ili kompleksnog sistema zaštite. U praksi zaštite,
najĉešće upotrebljavani su koncepti modela su funkcionalni i objektno-
orijentisani strukturni model arhitekture IS i sistema zaštite. Na najvišem,
strategijskom nivou apstrakcije u oblasti zaštite, ĉesto se koriste koncepti
reaktivnog i proaktivnog sistema zaštite. Detaljan pregled korišćenih
modela u oblasti zaštite moţe se naći i literaturi [5], [8],[25],[27].

Tehnologiju zaštite ĉine tehnike i hardversko-softverski alati (mehanizmi

i protokoli) implementirani u sisteme zaštite. U sistemu IKT zaštite pod
alatima se u širem smislu podrazumevaju: upravljački i operativni alati
(zakoni, standardi, program, plan, politike i procedure zaštite -
upravljačke i operativne kontrole) i tehnički alati (hardversko-softverski
mehanizmi i protokoli - tehničke kontrole) zaštite. Alati su sredstva za
realizaciju koncepata zaštite, a naĉini (metodi) primene alata u kontekstu
tehnologije zaštite nazivaju se tehnike zaštite, dokumentovane obiĉno u
tehniĉkoj dokumentaciji ureĊaja za zaštitu.

Procesni razvoj sistema zaštite zahteva definisanje i poznavanje procesa

zaštite. U metodologiji SE proces se moţe definisati na više naĉina. U
opštem sluĉaju to je skup ljudi, sredstava i povezanih aktivnosti
usmerenih za postizanje nekog jedinstvenog cilja; proces ima svoj
poĉetak i kraj, a u kontekstu sistema zaštite moţe biti i neprekidna
aktivnost (npr. nadzor i kontrola, obuka i edukacija). Redosled postupaka
(baziĉnih praksi) i aktivnosti u procesu zaštite definišu procedure zaštite.

Projekat zaštite je skup procesa koji imaju svoj poĉetak i kraj, tima za
realizaciju, tehnologija i njihovih meĊusobnih veza, koji su usmereni na
izvršavanje zajedniĉkih zadataka i imaju jedinstven cilj. Zbog
kompleksnosti savremenih IKT sistema, strateške inicijative (pod)sistema
zaštite retko se implementiraju jedinstvenim projektom i sistemskim

- 29 -
pristupom. Obiĉno se u praksi projekat kompleksnog sistema zaštite
(predstavljen akcionim planom u strategiji zaštite) razbija na manje
operativno upravljive projekte koji se mogu izvršiti za 3-6 meseci, sa
relativno manjim budţetom i koji se implementiraju prema prioritetima,
utvrĊenim na bazi bezbednosnih zahteva i analize rizika, [23].

- 30 -
2. METODOLOGIJE ZA RAZVOJ SISTEMA ZAŠTITE

2.1. Opšta metodologija za razvoj programa i sistema zaštite

U procesima razvoja programa i sistema zaštite generalno postoje tri

moguće metodologije koje koriste, [23]:

 politiku zaštite, i/ili

 upravljanje rizikom (analizu/procenu/kontrolu rizika) i/ili
 standarde najbolje prakse zaštite (ISO 17799, NIST SP 800-53
A,B,C).

Prve dve metodologije obezbeĊuju koncept klasiĉnog, preteţno

reaktivnog sistema zaštite, ili zaštite od poznatih napada. Treća
metodologija namenjena je za najviši nivo (idealne) zaštite, za
univerzalne tipove organizacija, poslovnog okruţenja i profila rizika i
zaštitu od poznatih i nepoznatih pretnji (tzv. proaktivnu zaštitu). Drugim
reĉima, ova metodologija ne uzima u obzir realno stanje konkretne
organizacije, pa za jednu organizaciju moţe biti idealna, a za drugu
suviše redundantna ili ne-efektivna. Ova metodologija daje dobre
rezultate u kombinaciji sa regularnom analizom rizika, koja obezbeĊuje
neophodne konkretne informacije za optimalnu zaštitu u funkciji
poslovnih ciljeva i misije organizacije.

Iako po svojoj prirodi reaktivni sistemi zaštite imaju proaktivnih

komponenti (IDS – detektori upada u sistem i sam koncept zaštite),
koncept proaktivne IKT zaštite od dinamiĉki promenljivih,
kombinovanih pretnji sa Interneta u suštini odreĊuje samo ĉinjenica da
proaktivni sistem zaštite obezbeĊuje zaštitu od poznatih i nepoznatih
pretnji. Koncept proaktivne zaštite kombinuje, [17]:

 obaveštenja vodećih CIRT (Computer Incident Response Team) i

CERT (Computer Emergency Response Team) timova u praćenju
tipova napada i ranjivosti sistema,
 savremenu tehnologiju za proaktivnu zaštitu od poznatih i nepoznatih
pretnji i
 procesni pristup zaštiti IKT sistema koji smanjuje kompleksnost
sistema zaštite.

- 31 -
2.2. Metodologija vektora zaštite (S-vektora)

Sa aspekta razvoja i izbora adekvatne metodologije za razvoj

programa zaštite, glavne karakteristike poslovnih IKT sistema za e-
Poslovanje su: brže uključivanje razvojne strategije poslovnog sistema i
eksperimentalne tehnologije sa potrebom njihove integracije, nedovoljno
jasni projektni ciljevi, česti zahtevi za fundamentalnim izmenama
sistema, nepoznati i nepoverljivi korisnici, zahtevi za brzom
implementacijom poslovnih i tehnoloških promena i postojanje mnogo
kreativnijih timova za razvoj.

Sve veći znaĉaj web aplikacija za savremeno e-Poslovanje, ali i znatno

veći nivo pretnji i faktora rizika, kao i potreba ĉešće analize rizika,
zahtevaju stabilne, kvalitetnije i merljive sisteme zaštite web aplikacija.
Postojeći standardi zaštite ne nude pouzdanu i celovitu metodologiju za
evaluaciju kvaliteta sistema IKT zaštite u celini. Za ocenu kvaliteta,
reinţenjering i poboljšavanje sistema zaštite web aplikacija i IKT sistema
za e-poslovanje, razvijena je metodologija vektora zaštite (S-vektora),
[26].

2.3. Koncept metodologije S-vektora

Metodologija S-vektora omogućava organizacijama da odrede

prioritete u implementaciji projekata reinţenjeringa postojećeg sistema
zaštite, evaluiraju strategiju za poboljšavanje i mere progres u
poboljšavanju sistema zaštite, a posebno je namenjena za validaciju
zaštite web aplikacija. Koristi sistem ponderisanja, integrišući
metodologije tri standarda zaštite, [25]:

1. ISO/IEC 17799, Code of Practice and Security Controles,

2. ISO/IEC 21827 ili model sazrevanja procesa zaštite (SSE CMM
– Security System Engineering Capability Maturity Model) i
3. ISO 15408 (CC- opšti kriterijumi za evaluaciju proizvoda zaštite).

Generalno metodologija S-vektora obuhvata sledeće funkcije:

bezbednosne zahteve za svaku web aplikaciju, koji se mapiraju u vektor
zahtevane zaštite aplikacije i sadrţe ţeljeni (ciljni, referentni) teţinski
faktor i periodičnu procenu zaštite web aplikacije sa odgovarajućim
teţinskim faktorom tekućeg vektora zaštite aplikacije, koji se uporeĊuje

- 32 -
sa referentnim u vektoru ciljne zaštite aplikacije, dajući meru progresa
sazrevanja procesa zaštite. U S-vektoru mapirana su tri tipa bezbednosnih
zahteva: tehnički, strukturni i proceduralni.

Tehničke komponente S-vektora ukljuĉuju servise i aplikacije zaštite,

kao što su kriptozaštita zaštita i jaka autentifikacija. Ove komponente u
najvećoj meri korespondiraju zahtevima standarda opštih kriterijuma
(CC) za evaluaciju proizvoda i sistem zaštite (ISO 15408).

Strukturne komponente obuhvataju strukture softvera i dizajna sistema

zaštite i obezbeĊuju veću bezbednosnu garanciju (assurance-sigurnost,
pouzdanost) servisa zaštite. Primeri su: razliĉiti tipovi automatskih
provera programskih kodova. Ove se komponente mogu aplicirati
primenom standarda ISO/IEC 17799 i ISO/IEC 21827 (SSE CMM).

Proceduralne komponente ukljuĉuju procedure za razvoj,

implementaciju i upravljanje koje obezbeĊuju pouzdanije servise zaštite.
Primeri su metodologija za razvoj programa (SSE CMM) i politike (ISO
17799) za upravljanje sistemom zaštite.

Što je najbitnije, metodologija S-vektora sadrţi i metriĉki sistem za

kvantitativnu evaluaciju bezbednosnih zahteva i aktuelnih rezultata
performansi implementiranog sistema zaštite. U okviru metriĉkog
sistema najinteresantniji su sistem ponderisanja teţinskim faktorima
komponenti S-vektora, preuzetih iz standarda ISO/IEC 17799 i sistem
merenja nivoa zrelosti kapaciteta procesa zaštite, preuzet iz SSE CMM
modela. Detaljniji opis primene standarda ISO/IEC 17799 i SSE CMM u
metodologiji S-vektora dat je u PRILOGU I 3B.

- 33 -
2.4. Prednosti i nedostaci metodologije S-vektora

Prednosti: SSE CMM model obezbeĊuje viši nivo apstrakcije

upravljanja zaštitom od ISO/IEC 17799. Metodologija S-vektora
omogućava korišćenje oba standarda. ISO/IEC 17799 obezbeĊuje
specifiĉne kontrole S-vektora, dok SSE CMM model uspostavlja zreo i
institucionalizovan okvir za upravljanje programom zaštite. MeĊutim, da
bi se ove kontrole razvile, monitorisale, merile i kontrolisale (SSE CMM),
neka infrastruktura zaštite mora biti već implementirana. Glavna prednost
integrisanja ISO/IEC 17799 kontrola zaštite je meĊunarodno priznavanje
ISO/IEC 17799 standarda, koji sadrţi sveobuhvatan set proceduralnih
kontrola iskoristivih za podršku zaštite web aplikacija. Glavna prednost
korišćenja SSE CMM za razvoj i odrţavanje programa zaštite je veća
bezbednosna garancija da će implementirani procesi dostići ţeljeni nivo
zrelosti i biti neprekidno odrţavani.
Nedostaci: Glavni nedostatak metodologije S-vektora je što nisu
definisana preklapanja i redundantnosti izmeĊu ova dva standarda, koja
se, u stvari, dopunjuju:
Primer 1: SSE CMM ima OP za Administraciju kontrola zaštite;
meĊutim, preporuĉene kontrole nisu obezbeĊene u samom modelu.
ISO/IEC 17799 naprotiv, preporuĉuje (U, O, T) kontrole zaštite – ukupno
128, ali ne obezbeĊuje detalje o tome kako ih treba administrirati.
Primer 2: ISO/IEC 17799 preporuĉuje periodiĉno izvršavanje procena
rizika. SSE CMM ide korak dalje u ovoj preporuci, procenjujući zrelost
procesa za procenu rizika.
Primer 3: Moguće je primeniti SSE CMM merenje nivoa zrelosti
kapaciteta procesa zaštite na ISO/IEC 17799 kontrole zaštite, pod
uslovom da je cilj ponderisanja procena zrelosti kontrole, a ne kvalitet
izlaznih rezultata kontrole.
Bez primene metodologije S-vektora mogu se izvršiti bezbednosna
kategorizacija i klasifikacija objekata IKT sistema, procena rizika, ili
izrada dokumenta politike zaštite, ali ne i odrţavati na ţeljenom nivou
kvaliteta, što bi moglo imati za posledicu neaţuran i neadekvatan
program i politike zaštite i neefektivan sistem zaštite.
Metodologija S-vektora sadrţi tehničke, proceduralne i strukturalne
komponente i zbog toga obezbeĊuje sveobuhvatniju procenu bezbednosti
i zaštite web aplikacija nego ISO/IEC 17799 i SSE CMM model

- 34 -
pojedinaĉno. Pošto bezbednosna kategorizacija i klasifikacija objekata
IKT sistema i procena rizika obezbeĊuju kritiĉne ulaze u bezbednosne
zahteve, efektivna implementacija S-vektora zahteva da ove aktivnosti
budu precizno izvršene. Projektni tim moţe preporuĉiti specifiĉne
metodologije za izvršavanje ovih aktivnosti.
Da bi se obezbedi efektivna implementacija S-vektora, otvorena pitanja
su: definisanje obima S-vektora; izbor rentabilnog alata za procenu
zaštite web aplikacija; implementacija S-vektora bez definisanja
administrativnog okvira; definisanje obima potrebne infrastrukture
zaštite; definisanje drugih strukturnih komponenti S-vektora (pored
proceduralnih) i definisanje kriterijuma za izbor metrike za ponderisanje.

- 35 -
3. MODELOVANJE SISTEMA ZAŠTITE

3.1. Strukturni modeli distribuiranog IKT sistema

Model je apstrakcija realnog sistema, a koristi se za prezentaciju

problema kojeg treba rešiti. Postoje ĉetiri generiĉka tipa modela: fizički,
narativni, grafički i matematički. Fiziĉki modeli (n.p.r. automobila)
koriste se u proizvodnji i graĊevinarstvu; narativni (reĉima i tekstom) su
najviše rasprostranjeni i koriste se u svim oblastima; grafiĉki se najviše
koriste u modelovanju tehniĉkih sistema, a matematiĉki modeli su
najprecizniji, mogu biti jednostavni i izuzetno kompleksni, a koriste se za
modelovanje (simulaciju) kritiĉnih i skupih procesa. U modelovanju IKT
i sistema zaštite koriste se narativni, grafiĉki i matematiĉki modeli. U
kategoriji narativnih modela nalaze se funkcionalni modeli (n.p.r. sistema
zaštite, procesa upravljanja rizikom i. t.d.). Grafiĉki modli u modelovanju
tehniĉkih sistema su brojni (n.p.r. procesa strateškog planiranja zaštite,
strateške politike zaštite, procene rizika i.t.d.). Egzaktni matematiĉki
modeli u oblasti zaštite retko se koriste, zbog visoke kompleksnosti i
neodreĊenosti brojnih parametara sistema zaštite (n.p.r. pretnji, faktora
rizika, uticaja pretnji, ranjivosti sistema i.t.d.).

Namena svakog modelovanja je da se smanji kompleksnost sistema. U

modelovanju sistema zaštite preuzeti su i koriste se svi klasiĉni modeli za
modelovanje IKT sistema. U PRILOG I 3A, pod A dat je pregled
klasiĉnih metodologija za razvoj IKT sistema: linearna (ţivotnog ciklusa,
vodopada), iterativna, sa brzim odzivom i.t.d.,. Pregled relevantnih
modela za modelovanje procesa analize rizika i razvoja sistema zaštite
dat je u PRILOGU I 3A pod B. Zbog kompleksnosti IKT i sistema
zaštite za projektovanje i razvoj sistema zaštite bolje rezultate pokazuju
strukturni i objektno orijentisani modeli.

Strukturni model zaštićenog (bezbednog) IKT sistema sadrţi tri glavne

komponente: skup objekata, pasivnih i aktivnih komponenti sistema koje
se koriste i kojima se pristupa na kontrolisan naĉin; skup subjekata,
aktivnih komponenti sistema koje koriste i pristupaju objektima i skup
pravila, na osnovu kojih subjekti koriste i pristupaju objektima, [24].
Strukturni modeli IKT sistema vrše dekompoziciju (klasifikaciju i
kategorizaciju) objekata sistema na skupove objekata, prema definisanim

- 36 -
kriterijumima (jedinstveni bezbednosni ciljevi, jedinstvene funkcije
i.t.d.), a odbacuju nebitne komponente i tako smanjuju kompleksnost
sistema. U sledećim primerima dati su razliĉiti tipovi primene strukturnih
modela:

a. Modelovanje IKT sistema. Osnovne karakteristike distribuiranih IKT

sistema su: teritorijalna udaljenost objekata, intenzivan obim razmene
informacija, široki spektar korišćenih tehnologija, integracija podataka
razliĉitih namena za razliĉite lokalne i udaljene subjekte, apstraktni
korisnici i vlasnici informacija u odnosu na fiziĉku strukturu, reţim
distribuirane obrade podataka, uĉešće u procesu funkcionisanja IKT
sistema velikog broja korisnika i ljudi, istovremeni pristup objektima
sistema većeg broja subjekata razliĉitih bezbednosnih kategorija, visok
stepen razliĉitosti raĉunarskih sistema, tehnika veze i sistemskih
programa, nehomogenost i nekoherentnost sistema zaštite ili nedostatak
komponenti zaštite.

Sa aspekta zaštite i zahteva za smanjenje kompleksnosti visoko

distriburanih sistema OSI modela, iz skupa svih mogućih komponenti
sistema, strukturni model obuhvata sledeće bezbednosno relevantne
objekte, koji se sa svoje strane mogu po potrebi dalje dekomponovati:
lokalna mreža, kanali i sredstva veze, komutacioni ureĎaji, upravljački
centar za obradu informacija, udaljeni legalni korisnici sistema,
nelegalni korisnici sistema (potencijalni maliciozni napadači), nosioci
informacija (magnetski, optički i dr.), izdvojene radne stanice
(terminali), tehnika za izradu rezervnih kopija (bekapovanje) i legalni
korisnici (ljudi), [8].

b. Modelovanje mehanizma logičke kontrole pristupa. U odreĊenom

vremenskom trenutku svi tipovi korišćenja i pristupa subjekata objektima
sistema stvaraju bezbedno stanje sistema. Model definiše bezbednosno
stanje sistema matricom pristupa – (M) koju ĉine: (redovi – subjekti (S),
kolone – objekti (O), a ćelije matrice – atributi pristupa (A), ili ovlašćenja
za pristup i korišćenje O od strane S. Dakle, elemente matrice (ćelije)
moţemo definisati sa:
M(S,O)=A,
što oznaĉava da subjekat S ima prava pristupa i korišćenja tipa A na
objektu O.

- 37 -
Svakom O u sistemu pridruţuje se referentni monitor, poseban kontrolni
program koji kontroliše pristup do tog O na sledeći naĉin:

1. subjekat S zahteva pristup do objekta O na naĉin a,

2. operativni sistem kreira trojku (S,O,a) i dostavlja je programu
referentnog monitora za objekat O,
3. monitor uporeĊuje atribute pristupa A(S,O) iz matrice pristupa,
primenjujući zahtev a,
4. ako je a jedan od atributa, pristup je dozvoljen, ako ne - odbija se.

c. Strukturno modelovanje mrežne IKT arhitekture obezbeĊuje

smanjenje kompleksnosti IKT sistema i sistema zaštite u ĉetiri koraka:
1.korak: analiza mreţnog plana i uklanjanje svake informacije koja nije
neophodna za izradu koncepta sistema osnovne zaštite;
2. korak: aţuriranje mreţnog plana ili delova plana (ako je podeljen u
sekcije) sa stvarnim stanjem topologije mreţe;
3. korak: odreĊivanje bezbednosnih zahteva za svaku grupu,
definisanjem kategorija bezbednosnih zahteva;
4. korak: grupisanje istih ili sliĉnih kategorija bezbednosnih zahteva u
zajedniĉku zonu bezbednosti.
Prvi korak je analiza mreţnog plana i uklanjanje svake informacije koja
nije neophodna za izradu koncepta sistema osnovne zaštite (eng. Security
Baseline), a izvršava se kroz sledeće procedure:
– priprema i revizija mreţnog plana (plana mreţne topologije),
– redukcija kompleksnosti identifikovanjem grupa sliĉnih objekata,
– skupljanje informacija o IKT sistemu,
– skupljanje informacija o aplikacijama i odnosnim informacijama.

Uloga modelovanja sistema osnovne IKT zaštite u procesu razvoja

programa i projektovanja sistema zaštite i mogući izlazi prikazani su na
Sl. 3.1, [4].

- 38 -
 OBJEKTI IKT SISTEMA

Analiza strukture IKT sistema

Procena bezbednosnih zahteva

Modelovanje

Objekti IKT sistema već u upotrebi: Planirani objekti IKT sistema:

Model=plan testiranja Model=plan razvoja

Sl.3.1. Izlaz modelovanja sistema osnovne IKT zaštite

Drugi korak je aţuriranje mreţnog plana ili delova plana (ako je

podeljen u sekcije) sa stvarnim stanjem topologije mreţe. Zatim se sve
identiĉne komponente kombinuju u jednu grupu koja se predstavlja u
strukturnom modelu mreţnog plana jednim objektom. Mreţne
komponente mogu biti grupisane u istu grupu ako su:

– sve istog tipa,

– imaju identiĉne ili skoro identiĉne osnovne konfiguracije,
– povezane u mreţi na isti ili skorio isti naĉin (n.p.r. na isti sviĉ),
– u istim administrativnim, infrastrukturnim i bezbednosnim
osnovnim uslovima,
– koriste iste aplikacije i.t.d.

Ako su ovi uslovi ispunjeni za sve komponente u jednoj grupi, onda sa

aspekta zaštite uzorak jedne grupe moţe biti predstavnik bezbednosnog
stanja grupe u celini. Najznaĉajniji momenat u grupisanju objekata IKT
sistema je grupisanje klijentskih raĉunara. Obiĉno u organizaciji postoji
veliki broj raĉunara, koji se moţe smanjiti na upravljiv broj grupa, ako se
sledi navedena procedura. Serveri koji izvršavaju iste ili sliĉne zadatke
mogu se, takoĊe, grupisati u jednu grupu. Kada se grupisanje svih
komponenti mreţnog plana izvrši, svaka grupa se u planu predstavlja sa
po jednim objektom.

Treći korak je odreĊivanje bezbednosnih zahteva za svaku grupu,

definisanjem kategorija bezbednosnih zahteva. Gubici ili šteta koji moţe

- 39 -
nastati kao rezultat gubitka poverljivosti, integriteta ili raspoloţivosti
informacija (servisa, aplikacija) tipiĉno se mogu grupisati u sledeće
scenarije pretnji, [4]:

– povreda zakona, regulativa ili ugovora,

– gubljenje ili smanjenje taĉnosti informacija,
– fiziĉke povrede,
– gubljenje ili slabljenje radnih rezultata,
– negativni efekti na ugled organizacije i
– finansijske posledice.

Ĉesto jedan sluĉaj gubitka ili štete moţe ukljuĉiti nekoliko kategorija
šteta. Na primer, pad aplikacije moţe spreĉiti da se izvrši bitan poslovni
zadatak, što u isto vreme moţe izazvati finansijske gubitke i gubitak
reputacije organizacije. Da bi se povukle jasne granice izmeĊu kategorija
bezbednosnih zahteva: Nizak, Srednji, Visok (ili druge sliĉne granulacije:
Osnovni do srednji, Visok, Vrlo visok), treba definisati gornje i donje
granice za svaki individualni scenario pretnji. Radne tabele u PRILOGU
I 3C mogu se koristiti da bi se razumeli i izabrali odgovarajući
bezbednosni zahtevi za dati nivo potencijalnih pretnji i njihov uticaj.

Četvrti korak smanjenja kompleksnosti IKT sistema i sistema zaštite

strukturnim modelovanjem je grupisanje istih ili sliĉnih kategorija
bezbednosnih zahteva u zajedniĉku zonu bezbednosti.

Strukturni model IKT sistema, sastavljen od tri komponente moţe biti

sasvim koristan za modelovanje arhitekture srednjih i velikih IKT
sistema za potrebe razvoja programa i sistema zaštite:

1. Klasifikacija (dekomponovanje) objekata arhitekture i

infrastrukture IKT sistema u bezbednosne zone sa istim ili
sliĉnim kategorijama bezbednosnih zahteva;
2. Jedinstven opis svakog tipa sistema/objekta u svakoj
bezbednosnoj zoni i
3. Formiranje matrice koja sumira tokove vaţnih podataka izmeĊu
zona.

Glavne prednosti definisanja bezbednosnih zona su smanjenje

kompleksnosti arhitekture sistema i pojednostavljenje dijaloga sa

- 40 -
upravom; grupisanje sistema/objekata sa sliĉnim bezbednosnim
zahtevima i smanjenje kompleksnost IKT sistema za sve aspekte zaštite.
U PRILOGU I 3D opisan je primer primene strukturnog modela i
odreĊivanja bezbednosnih zona u IKT sistema velike banke (2000 radnih
stanica, 150 raznih servera, u Internet okruţenju), [23].

3.2. Problemi i nedostaci strukturnog modelovanja

U klasiĉnom objektnom pristupu strukturno modelovanje zastarelo

najmanje iz dva razloga:

1. podele na aktivne (subjekte) i pasivne (objekte) i

2. što se svaki program (metod) realizuje od strane konkretnog
korisnika, pa je realizacija objekta sloţena, jer je objekat
instrument ispunjavanja volje korisnika i uvek se moţe smatrati
da korisnik direktno ili (po pravilu) indirektno na svoj rizik
zahteva od nekog objekta odreĊeni informacioni servis.

U tradicionalnom pristupu zaštiti vaţan zahtev je bezbednost

ponovljenog korišćenja objekata (pasivnih nosilaca informacija, kao što
su dinamiĉke memorije), što je u konfliktu sa fundamentalnim principom
skrivanja ponašanja objekata (inkapsulacije). Takav objekat nije moguće
oĉistiti spoljnim metodom (naizmeniĉnim ispisivanjem 0 i 1), osim ako
sam ne sadrţi odgovarajući metod. Ukoliko takav metod (alat) postoji,
pouzdanost ĉišćenja memorije zavisi od korektnosti njegove realizacije.

Jedan od ĉvrstih stereotipova meĊu specijalistima zaštite je tretiranje

podsistema zaštite OS (NOSSS-Native Operative System Security
Subsystem) kao dominantne komponente zaštite. Na zaštitu OS izdvajaju
se znatna sredstva na raĉun ostalih komponenti sistema realne zaštite. U
savremenim IKT sistemima sa višeslojnom arhitekturom klijent-server
tipa, OS ne kontroliše sve objekte sa kojima korisnici rade, kao ni
aktivnosti samih korisnika koji svoj pristup OS-u registruju i evidentiraju
odgovarajućim mehanizmima. Na taj naĉin, osnovna bezbednosna
funkcija NOSSS postaje zaštita prava privilegovanih korisnika
(administratora, supervizora i dr.) od napada regularnih korisnika
(interno zaposlenih), što je znaĉajno, ali se bezbednost tim merama ne
iscrpljuje.

- 41 -
Sledeći pristup je formiranje nivoa hardversko-softverskih mehanizama
zaštite u vidu sveobuhvatnih servisa zaštite, koji pretpostavljaju
ekonomski opravdane zaštitne mere sinhronizovane sa ţivotnim ciklusom
sistema. Ove mere treba da ukljuĉe: periodičnu procenu rizika; pravila i
procedure za izbor rentabilnih mera ublaţavanja rizika na prihvatljiv
nivo; obuku korisnika o bitnim faktorima rizika i aktivnostima za
ublaţavanje rizika; periodičnu proveru efektivnosti pravila i procedura;
upravljanje promenama u sistemu; nadzor i kontrolu sistema zaštite i
upravljanje vanrednim dogaĎajem i incidentom. Jedinstven naĉin
obezbeĊivanja bezbedne RM je uspostavljanje koherentnog sistema
zaštite koji radi kao jedna celina. Stepen zaštite informacija od
neovlašćenog pristupa i ilegalnih aktivnosti zavisi od organizacionih
mera, usmerenih na spreĉavanje: pristupa sistemu za obradu informacija,
neovlašćenog unosa podataka u memoriju, izmene ili brisanja
informacija, neovlašćenog korišćenja sistema za obradu informacija i
dobijenih podataka, pristupa IS posredstvom sospstvenih ureĊaja,
nekontrolisane predaja podataka, obrade podataka bez odgovarajućeg
zahteva, neovlašćenog ĉitanja i izmene ili brisanja podataka u procesu
predaje ili prenosa i dr.

Jedan od znaĉajnih problema zaštite informacija u savremenim visoko

distribuiranim sistemima je povećanje efikasnosti i kvaliteta upravljanja
zaštitom, [8].

U oblasti zaštite informacija slabo se koriste znanja i iskustva iz

objektno-orijentisanog pristupa, na kojem se zasniva projektovanje
savremenih IKT sistema i predstavlja isproban metod za smanjivanje
kompleksnosti IKT sistema i samog sistema zaštite. Svaki racionalan
metod za smanjenje kompleksnosti primenjuje princip dekompozicije,
koji podrazumeva da se kompleksni sistem na najvišem nivou moţe
dekomponovati u manji broj sastavnih i relativno nezavisnih objekata sa
minimalnim brojem meĊusobnih veza. Dekompozicija se moţe vršiti i na
niţim nivoima apstrakcije u narednim fazama.

Strukturni model se protivi algoritamskoj dekompoziciji, kojom se sistem

deli na funkcionalne objekte sistema i prikazuje funkcionalnim modelom.
Osnovni problem strukturnog pristupa je u tome što nije primenljiv u
ranoj fazi analize i modelovanja predmetne oblasti, kada se do algoritma
i funkcije dekompozicije još nije stiglo. Zato je nuţno uvesti model
„širokog spektra― koji nema takve konceptualne razlike sa realnim

- 42 -
sistemima i koji se moţe primenjivati u svim fazama razvoja i realizacije
kompleksnih sistema. Takve zahteve zadovoljava objektno-orijentisani
pristup.

3.3. Osnovni pojmovi metodologije objektno orijentisanog pristupa

Objektno orijentisani pristup koristi objektnu dekompoziciju

strukture IKT sistema, tj. ponašanje sistema opisuje se terminima
meĊusobnih dejstava objekata. U objektno-orijentisanom pristupu nema
pasivnih objekata, smatra se da su svi objekti istovremeno aktivni, a po
potrebi izazivaju naĉine ponašanja jedan drugoga. Detalji realizacije tih
ponašanja su skriveni (inkapsulirani), a povezivanje objekata dostupno je
samo interfejsu.

Za razumevanje pojma objekta IKT sistema zahteva se razumevanje

klasifikacije i kategorizacije objekata IKT sistema i uvoĊenje pojma
klase objekata. Generiĉki klasifikacija bilo kojih objekata mora da ima
sledeće atribute [13]:

1. MeĎusobnu isključivost – spreĉava preklapanja, klasifikacija u

jednu kategoriju iskljuĉuje sve ostale kategorije koje su
meĊusobno disjunktne;
2. Potpunost – unija svih kategorija obuhvata sve moguće
klasifikacije;
3. Nedvosmislenost – svaka klasifikacija mora biti jasna i precizna;
4. Ponovljivost – svaki proces klasifikacije mora biti ponovljiv i da
daje isti rezultat;
5. Prihvatljivost – svaka klasifikacija mora biti logiĉka i intuitivna;
6. Promenljivost – klasifikacija mora biti primenljiva u razliĉitim
sferama istraţivanja.

Pod kategorizacijom podrazumeva se klasifikacija svih objekata IKT

sistema u kategorije na koje se mogu primeniti svi navedeni atributi
klasifikacije, [8]. U kontekstu sistema zaštite, pod bezbednosnom
kategorizacijom podrazumeva se klasifikacija objekata IKT sistema u
kategorije sa jednakim bezbednosnim zahtevima i ciljevima, na koje se
mogu primeniti svi navedeni atributi klasifikacije. Bezbednosna
klasifikacija odnosi na bezbednosne nivoe informacija (n.p.r., interne,
poverljive SP, DT).

- 43 -
Klasa je apstrakcija skupa stvarnih karakteristika realnog sveta,
objedinjenih jednakom opštom strukturom i ponašanjem. Objekat je
elemenat klase, tj. apstrakcija odreĊene stvarnosti. Objekti su aktivni
elementi koji imaju unutrašnju strukturu i naĉin ponašanja koji se opisuje
tzv. metodom (ponašanja) objekta. Na primer, moţe se odrediti klasa
„korisnika―, koja oznaĉava opšti pojam korisnika sa opštim korisniĉkim
podacima i metodama ponašanja, a zatim objekat - „korisnik XY― sa
odgovarajućim konkretnim podacima i moguće posebnim naĉinom
ponašanja. Sledeća grupa vaţnih pojmova objektnog pristupa su
inkapsulacija, nasleĎivanje i polimorfizam.

Objektno orijentisani pristup karakterišu atributi: inkapsulacija,

nasleĎivanje i polimorfizam, koji poseduju komponente klasa objekata
IKT sistema i sistema zaštite, [8], [27]:

- inkapsulacija komponenti objekta, osnovni instrument smanjenja

kompleksnosti sistema podrazumeva skraćenu unutrašnju
strukturu objekta, detalja realizacije i naĉina ponašanja (metoda);
smanjuje sloţenost realizacije, odrţavajući vidljivim samo
znaĉajne interfejse na datom nivou aproksimacije;
- nasleĎivanje oznaĉava formiranje nove klase objekata na osnovu
postojeće sa mogućnošću dodavanja ili ponovnog odreĊivanja
podataka i naĉina ponašanja; dopušta razvoj komponenti u ranoj
fazi razvoja sistema, ne narušavajući integritet sloţenog objekta
(sistema zaštite); vaţan faktor smanjenja multiplikativnih
elemenata realnog sistema, gde se opšta informacija ne duplira,
nego se samo ukazuje na postojeće promene; na taj naĉin klasa-
potomak postaje koren nove klase-naslednika i
- polimorfizam sposobnost objekta da se svrsta u više od jedne
klase, što zavisi od aspekta i kriterijuma posmatranja objekta;
omogućava grupisanje objekata sa sliĉnim karakteristikama.

Vaţno je uoĉiti da nasleĊivanje i polimorfizam zajedno daju objektno

orijentisanom sistemu sposobnost modularne skalabilnosti (nadogradnje).
Komponente i sistem zaštite su upravo klasa objekata koji se konstantno
modifikuju i zahtevaju modularnu dograĊuju.

Grane objekta i nivo dekompozicije (detaljizacije) još su dve bitne

karakteristike objekata. Realni objekti po pravilu poseduju nekoliko
relativno nezavisnih karakteristika. U modelu objekta takve se

- 44 -
karakteristike nazivaju grane objekta. Na primer, u sistemu zaštite
definisane su tri osnovne grane objekata zaštite: raspoloživost, integritet i
poverljivost. Tako pojam grane objekta omogućava bolje od
polimorfizma, raznolikost aspekata posmatranja i apstrakcije objekata.

Pojam nivoa dekompozicije (detaljizacije) vaţan je ne samo za

vizuelizaciju objekata, nego i za sistematsku analizu sloţenih objekata,
predstavljenu u hijerarhijskoj formi. Sama po sebi ova karakteristika je
vrlo prosta: ako se tekući nivo hijerarhije razmatra sa nivoom detalja
n>0, sledeći se razmatra sa nivoom detalja (n-1). Objekat sa nivoom
detalja 0 smatra se da je atomizovan (nedeljiv). Nivoi detaljizacija
variraju kako za objekte tako i za grane objekta.

Veoma rasprostranjena konkretizacija objektno orijentisanog pristupa su

komponente objekta i kontejner. Komponenta objekta se moţe definisati
kao višestruko korišćeni sastavni elemenat objekta, a kontejner sadrţi
više komponenti i formira opšti kontekst meĊudejstava sa drugim
komponentama i okruţenjem. Jedan kontejner moţe imati ulogu
komponente drugog kontejnera. Pojmovima komponente i kontejnera
mogu se na suštinski naĉin predstaviti istovremeno sistem zaštite i
objekti IKT sistema koji se štite. Posebno, pojam kontejnera moţe
odrediti granice zone zaštite, ili perimetar zaštite, ili domena zaštite.
Komponente objekta raspolaţu sa svim karakteristikama objektno
orijentisanog pristupa:

- inkapsulacija komponenti objekta smanjuje sloţenost realizacije,

odrţavajući vidljivim samo znaĉajne interfejse;
- nasleĊivanje dopušta razvoj komponenti u ranoj fazi razvoja
sistema, ne narušavajući integritet sloţenog objekta (sistema
zaštite);
- polimorfizam omogućava grupisanje objekata sa sliĉnim
karakteristikama.

- 45 -
3.4. Primena objektno-orijentisanog pristupa u oblasti zaštite

Problem zaštite informacija veoma je sloţen: sloţeni su IKT sistem i

komponente sistema zaštite Za struktuiranje bezbednosnog cilja – razvoj
integrisanog sistema zaštite informacija i smanjenje kompleksnosti
zaštite, uvodi se skup grana informacionih objekata: raspoloživost,
integritet i poverljivost informacija, koje moţemo smatrati relativno
nezavisnim i ako su sve tri obezbeĊene, smatra se da je obezbeĊen i
zaštićen IKT sistem. U sledećem koraku, potrebno je struktuirati sredstva
za postizanje tog cilja uvoĊenjem novog skupa grana objekata sistema
zaštite: upravljačke, organizaciono-operativne i tehničke kontrole zaštite.

Obe grane objekata razmatraju se u principu sa razliĉitim nivoima

detalja. Zakoni, drugi normativni akti i standardi usmereni su na subjekte
u informacionom okruţenju bez obzira na organizacione nadleţnosti
(pravna ili fiziĉka lica), dok se administrativne mere odnose na sve
subjekte u predmetnoj organizaciji. Proceduralne mere odnose se na
pojedince ili grupe korisnika-ljudi u okviru IKT sistema, a hardversko
softverske – na tehniĉke mehanizme i protokole zaštite. Na taj naĉin,
prelaskom sa jednog na drugi nivo zaštite primenjuje se karakteristika
nasleĎivanja – svaki sledeći nivo ne menja se nego dopunjuje sa
prethodnim nivoom zaštite, što omogućava primenu slojevitog koncepta
zaštite, kao i polimorfizma – na primer, subjekti nastupaju u razliĉitim
ulogama, kao inicijatori administrativnih mera, faktori upravljanja
sistemom zaštite i obiĉni korisnici koji se podĉinjavaju tim merama
zaštite.
Na sve relativno nezavisne grane deluje i princip inkapsulacije, što
suštinski oznaĉava da je svaka grana „relativno nezavisna―. Osim toga,
ova dva skupa grana moţemo nazvati ortogonalnim, pošto za fiksnu
granu u jednom skupu (na primer, raspoloživost) treba razmatrati sve
elemente iz drugog skupa grana (upravljaĉke, operativne i tehniĉke
kontrole). Ortogonalnih skupova nema mnogo: dva skupa sa brojem
elemenata od 3-4 daje 12 kombinacija ortogonalnih skupova, što je još
uvek prihvatljiv nivo kompleksnosti.
Primer objektno-orijentisane dekompozicije IKT sistema na više nivoa u
procesu razvoja programa i sistema zaštite prikazan je u PRILOGU I
3E, [8].

- 46 -
4. REZIME

Sistem zaštite odrţava bezbednosno stanje IKT sistema na

ţeljenom nivou zaštićenosti. Strategija zaštite obezbeĊuje okvir za razvoj
sistema zaštite za dugoroĉne bezbednosne ciljeve, pošto sadrţi
konsolidovanu viziju tekućeg i ţeljenog bezbednosnog stanja sistema. Za
razvoj i implementaciju programa i strateškog plana zaštite treba
definisati, razviti i implementirati ĉetiri kljuĉna koncepta sistema zaštite:
metodologiju, tehnologiju, operativnu praksu i odgovornosti u zaštiti
IKT sistema.

Metodologije i okviri u oblasti zaštite koriste se na osnovu internih

standarda i/ili opšte prihvaćenih industrijskih standarda. Oba konteksta su
jednako znaĉajna. Metodologije i okviri grupišu se zajedno, najĉešće kao
upravljačke kontrole, pošto dodaju strukturu procesima zaštite. Svaka
metodologija u potpunosti je odreĊena, definisanjem: principa,
koncepata (modela), metoda upotrebe (tehnika i alata) i procesa razvoja
(redosleda izvršavanja postupaka ili procedura primene alata).

Opšta metodologija razvoja programa i sistema zaštite generalno koristi:

politiku zaštite, i/ili /procenu rizika (tzv. reaktivne zaštite) i/ili standarde
najbolje prakse zaštite (tzv. proaktivne zaštite.

Metodologije S-vektora, kombinujući standarde ISO 15408-CC Criteria,

ISO/IEC 17799 i ISO/IEC 21827, omogućava organizacijama da odrede
prioritete u implementaciji projekata reinţenjeringa postojećeg sistema
zaštite, evaluiraju strategiju za poboljšavanje i mere progres u
poboljšavanju sistema zaštite, a posebno je namenjena za validaciju
zaštite web aplikacija.

Tehničke komponente S-vektora ukljuĉuju servise i aplikacije zaštite,

kao što su kriptozaštita zaštita i jaka autentifikacija i u najvećoj meri
korespondiraju zahtevima standarda zajedniĉkih kriterijuma (CC) za
evaluaciju proizvoda i sistem zaštite (ISO 15408). Proceduralne i
strukturne komponente S-vektora obezbeĊuje kombinacija standarda
ISO/IEC 17799 i ISO/IEC 21827 (SSE CMM). Osnovna prednost
integrisanja ISO/IEC 17799 kontrola u proceduralne komponente S-
vektora je to što je ISO/IEC 17799 standard meĊunarodno priznat i
sadrţi sveobuhvatan set proceduralnih kontrola koje se mogu koristiti za
podršku zaštite web aplikacija. Osnovna prednost integrisanja ISO/IEC

- 47 -
21827 (SSE CMM) za razvoj i odrţavanje okvira zaštite je to što se
sprovoĊenjem modela obezbeĊuje veća bezbednosna garancija da će
implementirani procesi zaštite dostići ţeljeni nivo zrelosti i da će biti
neprekidno odrţavani. Metodologija S-vektora sadrţi tehničke,
proceduralne i strukturne komponente i zbog toga obezbeĊuje
sveobuhvatniju procenu bezbednosti i zaštite web aplikacija nego
ISO/IEC 17799 i SSE CMM model pojedinaĉno, jer ni jedan standard ne
sadrţi sva tri tipa komponenti.

Za razvoj sistema IKT zaštite mogu se koristiti brojni klasiĉni modeli za

projektovanje IKT sistema i procenu rizika (u ţivotnom ciklusu,
vodopada, sa brzim odzivom i dr.). Bolje rezultate daju funkcionalni,
strukturni i objektno orijentisani modeli, ĉija je osnovna prednost
smanjenje kompleksnosti analize IS i sinteze sistema zaštite.

Objektno-orijentisani pristup karakterišu pojmovi inkapsulacija

(smanjuje sloţenost realizacije, odrţavajući vidljivim samo znaĉajne
interfejse na datom nivou aproksimacije), nasleĎivanje (dopušta razvoj
komponenti u ranoj fazi razvoja sistema, ne narušavajući integritet
sloţenog objekta-sistema zaštite) i polimorfizam, (omogućava grupisanje
objekata sa sliĉnim karakteristikama). Za struktuiranje bezbednosnog
cilja (razvoj integrisanog sistema zaštite informacija) i smanjenje
kompleksnosti zaštite, uvodi se grana informacionih objekata:
raspoloživost, integritet i poverljivost, a za struktuiranje sredstva za
postizanje tog cilja grana objekata sistema zaštite: upravljačke,
operativne i tehničke kontrole zaštite.

- 48 -
5. KLJUĈNI TERMINI

Mehanizmi i protokoli zaštite: su pojedinaĉni algoritmi, metodi, ili

hardversko-softverski moduli za izvršavanje bezbednosnih funkcija, koji
eliminišu bezbednosne probleme u IKT sistemu; u logiĉkom smislu
predstavljaju naĉin realizacije servisa zaštite.
Mera(e) zaštite: odobrene minimalne mere zaštite koje će, kada se
korektno koriste, ublaţiti ili redukovati rizik nastao iskorišćenjem
specifiĉnih ranjivosti, koje bi mogle kompromitovati IKT sistem.
Metodologija: nauka o metodama; sistem organizovanja: principa,
koncepata (modela), metoda, tehnika i alata, procesa razvoja (redosleda
aktivnosti), kontrole razvoja procesa.
Model: aproksimacija realnog sistema koja najpribliţnije predstavlja
tokove procesa, funkcionisanje i/ili druge relevantne atribute realnog
sistema; formalni i funkcionalni modeli.
Nivo bezbednosti: kvalitativna ili kvantitativna mera stanja bezbednosti.
Objekat zaštite: fiziĉki i/ili logiĉki objekti IKT sistema, koji se štite
implementiranim sistemom zaštite, primarno - sa neposrednom zaštitom
podataka i informacija i/ili sekundarno - sa krajnjim ciljem zaštite
podataka i informacija.
Objekti IKT sistema: sve komponente sistema, ureĊaji, sistemski i
aplikativni programi, procedure, protokoli upravljaĉke strukture i.t.d;
mogu biti fizički (raĉunarski sistemi - serveri, radne stanice, ruteri sviĉevi
i.t.d.), logički (sistemski programi, aplikativni programi, softverski alati)
i korisnički (podaci, informacije, aplikacije) objekti IKT sistema koji
procesiraju, skladište ili prenose digitalne podatke i informacije.
Okvir: ambijent u kojem se nešto rešava (zakonski, normativni,
metodološki).
Pouzdanost (funkcionalna, tehniĉka, operativna): korektno
funkcionisanje komponenti, ureĊaja, podsistema i sistema u operativnom
okruţenju, sa performansama parametara u propisanim granicama.
Poverljivost informacija/sistema: stanje u kojem informacije/sistemi
nisu dostupni neovlašćenim korisnicima.
Princip: opšte prihvaćena naĉela, polazne osnove koje se obiĉno uzimaju
bez dokazivanja (aksiomatski).
Procedura: definisan i uspostavljen naĉin rada, rutina, ustanovljen naĉin
odvijanja procesa.
Procena rizika: Procena (evaluacija) rizika bazirana na efikasnosti
postojećeg sistema zaštite, verovatnoća da će ranjivosti sistema biti

- 49 -
iskorišćene i da će nastale posledice kompromitovati objekte IKT
sistema.
Proces: skup aktivnosti koje se izvršavaju da se postigne odreĊena
namena, koje imaju svoj poĉetak i kraj, a mogu se izvršavati iterativno,
rekurzivno i/ili konkurentno; izvršen proces je onaj kojeg je sistem
inţenjer stvarno izvršio i koji proizvodi namenjeni proizvod rada;
upravljan proces je izvršen proces, koji je planiran u politici zaštite
definisan proces je upravljan, kontrolisan, revidiran i koji se rigorozno
izvršava; kvantitativno upravljan proces je dobro definisan proces koji
se upravlja nekom kvantitativnom statistiĉkom metrikom i ĉiji se izlazni
rezultati mogu predvideti; optimalan proces je kvantitativno upravljan,
koji se prilagoĊava promenama okruţenja i sa kojim se moţe meriti
uticaj pretnji na poslove organizacije; kapacitet procesa: opseg
oĉekivanih rezultata koji mogu biti dostignuti ako se izvrši neki proces;
izvršavanje procesa: mera stvarnih rezultata koji se postiţu
sprovoĊenjem nekog procesa; zrelost procesa: mera do koje je specifiĉni
proces eksplicitno izvršen, upravljan, definisan, kvantitativno meren i
kontrolisan i adaptivan (daje rezultate u promenljivom okruţenju).
Ranjivost: karakteristika sistema koja dopušta da se realizuje dogaĊaj
pretnje.
Raspoloţivost informacija/sistema: stanje u kojem se
informacijama/sistemima moţe pristupati po potrebi; mogućnost
pristupa sistemima, programima, servisima i informacijama kada
je to potrebno i bez nepotrebnog kašnjenja.
Rizik: mera verovatnoće da će posledice nekog dogaĊaja prouzrokovati
kompromitaciju objekata IKT sistema.
Scenario pretnje: specifiĉan agent pretnje koji preduzima specifiĉan tip
napada u pokušaju da kompromituje (na jedan ili više naĉina) jedan ili
više delova objekata organizacije.
Servis zaštite: proces zaštite koji ima svoj poĉetak i kraj, a izvršava se
izvršavanjem skupa bezbednosnih funkcija sistema zaštite, koje obavljaju
mehanizmi i protokoli zaštite.
Sigurnost sistema: mera subjektivnog osećaja ili ubeĊenja da je sistem
bezbedan, da mu ne preti nikakva opasnost jer je zaštićen (osiguran) i
veruje se da je mala verovatnoća negativnih uticaja faktora rizika; u
semantiĉkom znaĉenju sinonim bezbednosti sistema.
Stanje: opis objekata sistema, pretnji, sistema zaštite i njihovog
okruţenja, kada se zadrţava dati skup uslova. Opis stanja je koristan za
modeliranje promena koje se mogu desiti izmeĊu dva stanja.

- 50 -
Strategija: sveobuhvatni, opšti koncept (put, naĉin, redosled) promene
stanja bezbednosti IKT sistema.

- 51 -
6. LITERATURA

1. Badenhurst, K. and Eloff, J., Computer Security Methodology:

Risk Analysis and Project Definition, Computers & Security,
Elsevier Press, New York, Vol. 9, 1990.
2. Bennett, S.P., and Kailay, M.P., An Application of Quantitative
Risk Analysis to Computer Security for the Commercial Sector,
The 8th Annual Computer Security Applications Conference,
IEEE Computer Society Press, New York, 1992.
3. Bilbao, Alfonso, "TUAR: A Model of Risk Analysis in the Security
Field", The Carnahan Conference on Security Technology, IEEE
Press, New York, 1992.
4. BSI (Federalni IS Nemaĉke), IT Baseline Protection Manual,
http://www.bsi.bund.de/gshb, juli 2005.
5. Carrol M.J., Computer Security, Butterworth-Heinemann, 1997.
6. CCIMB-99-031, Common Criteria for Information Technology
Security Evaluation, Part 1: Introduction and general model,
Version 2.1, http://www.commoncriteria.org, 1999.
7. CRAMM, http://www.crammusergroup.org.uk, 2004.
8. Domarev V.V.,Защита информации и безопасность
компьютерных систем, http://www.security.ukrnet.net/, 1997.
9. Drake, David L. and Morse, Katherine L., The Security – Specific
Eight Stage Risk Assessment Methodology, Proceedings of the
17th National Computer Security Conference, Baltimore,
Maryland, October 1994.
10. GAISP –Generally Accepted Information Security Principles,
http://www.gaisp.org, 2003.
11. Garrabrants, W. M.; Ellis III, A. W.; Hoffman, L. J. and Kamel,
M., "CERTS: A Comparative Evaluation method for Risk
Management Methodologies and Tools", The 6th Annual
Computer Security Applications Conference, IEEE Computer
Society Press, New York, 1990.
12. Hefner Dr. R., Warren M., System Security Engineering
Capability Maturity Model, TRW, CA, rick.hefner@trw.com,
1997.
13. Howard D., J., An Analysis of Security Incidents on the Internet
1989-1998, Thesis for the degree of doctor of philosophy,
Carnegie Mellon University, 1997.
14. Introduction to the OCTAVE®Approach,
http://www.cert.org/octave

- 52 -
15. ISACA, Information Systems Audit and Control Association,
http://www.isaca.org, 2003.
16. ISO/IEC 17799:2000, Information Technology – Code of practice
for information security management, http://www.iso.org, 2003.
17. ISS, Dynamic Threat Protection™ : A New Definition for
Information Security, 2005.
18. Lavine, Charles H.; Lindell, Anne M. and Guarro, Sergio B., The
Aerospace Risk Evaluation System (ARiES) Implementation of a
Qualitative Risk Analysis Methodology for Critical Systems,
Proceedings of the 17th National Computer Security Conference,
Baltimore, Maryland, October 1994.
19. Lee A., Brewer T., Information security within the system
development life cycle, Jones Computer Security Division
Information Technology Laboratory NIST,
http://www.itl.nist.gov/, 2004.
20. OCTAVE®Method Implementation Guide,
http://www.cert.org/octave/osig.html
21. Orlandi, Eugenio, The Cost of Security, The Carnahan Conference
on Security Technology, IEEE Press, New York, 1991.
22. Ozier, W., Risk Analysis and Assessment, Handbook of
Information Security Management 1999, CRC Press, Boca Raton,
Florida, 1999.
23. Purser S., A practical guide to managing information security,
Artech House, Boston, London, www.artechhouse.com, 2005.
24. Rodić B., ĐorĊević G., Da li ste sigurni da ste bezbedni,
Produktivnost AD, Beograd, 2004.
25. Russel D. and Gangemi G.T. sr, Computer Security Basics,
O‘Reilly and Ass., 1995.
26. Spears J., Barton R., Hery W., An Analysis of How ISO 17799
and SSE-CMM Relate to the S-vector Methodology,
http://www.ebrc.psu.edu, August 2004.
27. Wendy B., Moshel B., UML i Rational Rose 2002, Kompjuter
biblioteka, Beograd, 2005.

- 53 -
4. PRINCIPI ZAŠTITE

0. UVOD

Kada proučite ovo poglavlje razumećete:

- koncept i značaj principa zaštite

- sistemske principe zaštite (nikada sam, podela dužnosti,..)
- opšte prihvaćene principe zaštite (GAISP)
- funkcionalne principe zaštite (GAISP)
- detaljne principe zaštite (GAISP)

Prema teoriji sistemskog inţenjerstva (SE) princip zaštite je

fundamentalna istina, ili zakonitost koja se uzima bez dokazivanja kao
osnova za izvršavanje racionalne aktivnosti u procesu realizacije nekog
koncepta sistema zaštite.
Generalno prihvaćeni principi zaštite informacija (GAISP-Generaly
Accepted Information Security Principles) generisani su na osnovu
kolaborativnog rada ekspertskih timova iz više od 10 zemalja sveta (EU,
SAD, Kanade, Australije i.t.d.) i na osnovu brojnih standarda (OECD,
ISO 17799, COBIT i dr.), [2], [8], [11], [13].
Koncept opšte prihvaćenih principa zaštite (GAISP) razlikuje se od
koncepta univerzalno prihvaćenih principa zaštite, nasleĊenih iz oblasti
upravljanja informacionim sistemima i implicira da svaki opšte
prihvaćeni princip zaštite u odreĊenim sluĉajevima moţe imati izuzetak.
GAISP principi zaštite informacija aţuriraju se svake 3 godine.
Specijalisti zaštite treba da ih koriste u procesu projektovanja sistema
zaštite, proizvoĊaĉi u proizvodnji komponenti i ureĊaja zaštite, a vlasnici
informacija i menadţeri treba da ih implementiraju u program zaštite.
GAISP principi odnose se na fiziĉke, tehniĉke i administrativne
komponente sistema zaštite, a dele se u tri kategorije: opšte, funkcionalne
i potpune (detaljne) principe zaštite, koje se koriste da sakupe,
komentarišu i organizuju principe zaštite. Opšti principi odnose se na
upravljanje, funkcionalni – na operativno upravljanje, a potpuni - na
praksu zaštite i specijaliste zaštite.
U širem smislu termin principi zaštite informacija ukljuĉuje principe,
standarde, konvencije i mehanizme i protokole zaštite. Konzistentni
principi zaštite osnovni su gradivni elementi na kojima se zasnivaju
procesi upravljanja sistemom zaštite.

- 54 -
1. SISTEMSKI PRINCIPI ZAŠTITE

Sistemski principi zaštite su prvi primenjeni principi zaštite

preuzeti iz procesa upravljanja IKT sistemom (što implicira termin
„sistemski―). Obuhvataju personalne, organizacione i operativno
primenjene opšte prihvaćene i u praksi potvrĊene kadrovske i
organizacione mere u IKT sistemu, koje spreĉavaju sukob nadleţnosti i
interesa i povećavaju opštu bezbednost resursa IKT sistema. Ovi su
principi baza za implementaciju GAISP principa zaštite.

U funkcionalnom modelu principa upravljanja sistemom zaštite,

sistemski principi zaštite IKT sistema podrazumevaju obavezan okvir u
koga se ugraĊuju specifiĉni GAISP principi zaštite i obuhvataju (detaljno
opisane u PRILOGU I 4A), [17]:

1. nikada sam,
2. rotacije radnih mesta,
3. razdvajanje duţnosti i
4. principe upravljanja IKT sistemom.

- 55 -
2. OPŠTE PRIHVAĆENI PRINCIPI ZAŠTITE (GAISP)

2.1. Namena GAISP principa zaštite

Osnovna namena GAISP principa je da pomogne u upravljanju i

projektovanju sistema zaštite informacija, vlasnicima informacija,
specijalistima zaštite, proizvoĊaĉima komponenti zaštite i organizacijama
koje se bave definisanjem principa zaštite.

GAISP principi zaštite imaju višestruku upotrebljivost i koriste se da, [2]:

 Promovišu dobru praksu zaštite svih tipova poslovnih sistema;

 Obezbede referentni nivo principa, prakse i usaglašenih mišljenja u
sistemu zaštite;
 Motivišu poslovne sisteme da podrţavaju GAISP principa zaštite;
 Povećaju uverenje menadţerske strukture da je zaštita konzistentna i
merljiva;
 Povećaju operativnu rentabilnost u dobro obezbeĊenom i
kontrolisanom okruţenju;
 Smanje troškove proizvoda za zaštitu;
 Odrţe funkcionalnost upravljanja zaštitom na bazi skupa pravila,
metrike i standarda;
 Omoguće sertifikaciju sistema zaštite i samostalno kreiranje politika
zaštite;
 Obezbede veće poverenje i podršku upravne strukture merama
zaštite;
 Povećaju efikasnost i efektivnost servisa i specijalista zaštite,
promovisanjem najbolje prakse zaštite i smanjenjem dupliranja
kreativnih aktivnosti;
 Saĉuvaju javno poverenje u sposobnost organizacije da suvereno
upravlja zaštitom;
 Obezbede globalnu harmonizaciju principa zaštite kulturološko
razliĉitih sredina;
 Promovišu i povećavaju poverenje kupaca i prihvatljivost proizvoda;
 Obezbede osnovu za razvoj informacionog društva i kontrole
privatnosti i zaštite i
 Obezbede brţi razvoj metodologija i tehnologije sistema zaštite i
njihove artikulacije.

- 56 -
2.2. Struktura GAISP principa zaštite

GAISP principi su sveobuhvatna hijerarhija instrukcija i uputstava za

obezbeĊenje opšte prihvaćenog, konzistentnog, praktiĉnog okvira za
zaštitu informacija. GAISP preporuĉuje tri nivoa principa zaštite,
namenjenih profesionalcima koji su odgovorni za zaštitu na tehniĉkom,
operativnom i upravljaĉkom nivou:

1. Opšti principi zaštite usmeravaju upravljaĉku strukturu, obuhvataju

smernice i pomaţu organizaciji da definiše efektivnu strategiju
zaštite;
2. Funkcionalni principi zaštite, gradivni blokovi opštih principa,
detaljnije definišu taktiku izgradnje efektivne arhitekture sistema
zaštite.
3. Potpuni (detaljni, kompletirani) principi zaštite, namenjeni za
profesionalce u zaštiti, koriste funkcionalne principe kao okvir i
obezbeĊuju specifiĉna, sveobuhvatna uputstva za dnevne aktivnosti u
procesu upravljanja rizikom i sistemom IKT zaštite.

U primeni GAISP principa specijalisti zaštite treba da obezbede da je

svaki princip:
 precizno definisan, kompletan i konzistentan,
 usaglašen sa navedenim bezbednosnim ciljem,
 tehniĉki racionalan i prihvatljiv,
 dobro prezentiran, gramatiĉki i jeziĉki korektan i
 upodobljen primenljivim standardima i uputstvima zaštite.

GAISP principi zaštite struktuirani su i opisani u sledećem standardnom

formatu:
 naziv opšteg principa zaštite,
 definicija,
 opis (objašnjenje) i
 primer principa.

Primer:
Ime: Princip kontrolisane odgovornosti (accountability)
Definicija: Ovlašćenja i odgovornosti moraju u sistemu zaštite biti jasno
definisani, shvaćeni liĉno prihvaćeni i kontrolisani.

- 57 -
Objašnjenje: Kontrolisana odgovornost karakteriše sposobnost da se
kontrolišu akcije svih uĉesnika koji interaktivno rade sa informacijama i
IS. Uloge i odgovornosti se jasno definišu, identifikuju i dodeljuju
ovlašćenja pristupa osetljivim i kritiĉnim informacijama i drugim
digitalnim objektima IS, zaposlenim na svim nivoima organizacije.
Odnosi izmeĊu uĉesnika, procesa i informacija moraju biti jasno
definisani, dokumentovani i prihvaćeni od strane svih uĉesnika. Svi
uĉesnici u sistemu zaštite moraju preuzeti odgovornosti za ovlašćenja
koja su im dodeljena.
Primer: Na osnovu pregleda i analize bezbednosno relevantnih dogaĊaja
u log datoteci sistema, potrebno je da se kontrolišu i nadziru kritiĉni
digitalni objekti (DO). Log datoteka sadrţi informacije o svim izmenama,
dodavanjima ili brisanjima informacija i informiše korisnike ili procese
da su akcije izvršene.

2.3. Opšti principi zaštite

Opšti principi zaštite, obuhvaćeni su uputstvima na visokom

nivou i pomaţu organizaciji da definiše efektivnu strategiju zaštite.
Namenjeni za upravljanje sistemom zaštite, po svojoj prirodi su
fundamentalni, retko se menjaju i obuhvataju atribute zaštite
raspoloživosti, integriteta i poverljivosti informacija. Drugim reĉima,
bezbednost i zaštita informacija postiţu se kroz oĉuvanje odgovarajuće
poverljivosti, integriteta i raspoloţivosti informacija.

Opšte principe zaštite objavio je komitet OECD, a prihvatio NIST

(SAD) sa neznatnim proširenjem. Na bazi ovih, generisani su sledeći
opšti GAISP principi zaštite:

1. Princip odgovornosti (ovlašćenja i odgovornosti): ovlašćenja i

odgovornosti moraju u sistemu zaštite biti jasno definisani,
shvaćeni, prihvaćeni i kontrolisani.
2. Princip stalnog preispitivanja i procene: rizik za informacije i
druge objekte IKT sistema mora se regularno periodiĉno
procenjivati zbog stalne promene okruţenja.
3. Princip svesti o potrebi zaštite: svi uĉesnici u IKT sistemu
(vlasnici, specijalisti zaštite, korisnici) treba da budu adekvatno
upoznati o primenljivim pretnjama za bezbednost IKT sistema,
tehnologijama zaštite informacija.

- 58 -
4. Princip demokratičnosti (jednakosti): u procesima uspostavljanja
politika zaštite, izbora, implementacije i nametanja kontrola
zaštite, treba jednako uvaţavati liĉna prava i dostojanstvo svakog
uĉesnika.
5. Etički princip: informacije koje se štite treba da budu moralno
prihvatljive i iskoristive, a administriranje sistema zaštite treba da
se izvršava u skladu sa opšte prihvaćenim etiĉkim kodeksom
ponašanja.
6. Princip integracije: principi, standardi, konvencije i mehanizmi
zaštite treba da budu meĊusobno koordinirani, komplementarni i
integrisani u politike i procedure zaštite i sistem kontrola zaštite u
celom IKT sistemu.
7. Princip multidisciplinarnosti: principi, standardi, konvencije i
mehanizmi zaštite treba da sveobuhvatno ukljuĉuju sve relevantne
aspekte razliĉitih nauĉnih disciplina.
8. Princip proporcionalnosti: kontrole zaštite treba projektovati
proporcionalno proceni rizika od izmene, otkrivanja ili
nedostupnosti informacija.
9. Princip blagovremenosti: sve odgovorne strane i razliĉite
komponente u sistemu zaštite treba da deluju i reaguju
blagovremeno i koordinirano na spreĉavanju ili odbijanju napada
na IKT sistem.

- 59 -
2.4. Funkcionalni principi zaštite

Funkcionalni principi zaštite brojniji su i detaljniji od osnovnih,

koriste se za razvoj još brojnijih potpunih principa zaštite, a menjaju se sa
glavnim promenama okruţenja i tehnologija zaštite. Predstavljaju
gradivne blokove opštih principa zaštite. Sa aspekta upravljanja zaštitom,
definišu preporuke za implementaciju i praksu primene kontrola zaštite, a
obuhvataju sledeće principe:

Politika zaštite: Menadţment obezbeĊuje da su politike, standardi,

procedure i uputstva za osnovnu zaštitu, sveobuhvatno razvijeni,
implementirani i odrţavani. Politika zaštite mora pripisati odgovornosti i
prava pristupa svim uĉesnicima i nivoe prihvatljivog rizika.
Obuka i razvoj svesti o potrebi zaštite: Menadţment se obavezuje da sve
zaposlene na odgovarajući naĉin upozna sa svim elementima politika
zaštite, odgovornostima i da svi steknu svest o potrebi zaštite. Obuka u
sistemu zaštite ukljuĉuje standarde zaštite, osnovne kontrole zaštite,
procedure, odgovornosti, odnosne mere prinude i sankcije za ne-
usaglašenost prakse sa normativima i standardima zaštite.
Odgovornost: Menadţment organizacije obavezuje se da pripiše i
kontroliše odgovornosti i prava svih uĉesnika u IKT i sistemu zaštite za
pristup i korišćenje informacija (dodavanje, izmenu, kopiranje i brisanje)
i drugih IKT resursa. Za sve bezbednosno znaĉajne dogaĊaje, sistem
zaštite mora omogućiti registrovanje datuma, vremena pristup objektu,
radi kontrole odgovornosti upotrebe ovlašćenja svakog legalnog
korisnika.
Upravljanje objektima IKT sistema: Menadţment rutinski aţurira i
vrednuje katalog (inventar) objekata IKT sistema, odreĊuje nivo
osetljivosti i kritiĉnosti svakog objekta. Informacije i podaci kao
jedinstveni digitalni objekti IKT sistema moraju biti identifikovani,
bezbednosno klasifikovani, a za njihovu zaštitu pripisane odgovornosti.
Upravljanje fizičkom i zaštitom okruženja: Menadţment se obavezuje
da kompenzuju rizik koji je inherentan internom i eksternom fiziĉkom
okruţenju u kojem se informacioni objekti IKT sistema procesiraju,
skladište, prenose ili koriste.
Upravljanje personalnom zaštitom: Menadţment se obavezuje da
uspostavi i verifikuje kvalifikacije koje se odnose na integritet liĉnosti,
znanja potrebna za obavljanje poslova i tehniĉku konkurentnost svih lica
koji pristupaju objektima IKT sistema za opštu podršku.

- 60 -
Upravljanje incidentom: Menadţment se obavezuje da obezbedi
kapacitete za upravljanje kompjuterskim incidentom i minimizira uticaj
na poslove organizacije i verovatnoću ponavljanja sliĉnog incidenta.
Upravljanje zaštitom u životnom ciklusu IKT sistema: Menadţment je
odgovoran da obezbede zaštitu u svim fazama ţivotnog ciklusa IKT
sistema.
Kontrola pristupa: Menadţment se obavezuje da uspostavi odgovarajuće
kontrole za balansiranje potreba za pristup informacijama i drugim
objektima IKT sistema za opštu podršku, u odnosu na prihvatljivi nivo
rizika.
Planiranje kontinuiteta rada i vanrednih dogaĎaja: Menadţment se
obavezuje da planira rad IKT sistema u vanrednim dogaĊajima i
obezbedi kontinuitet poslovanja organizacije.
Upravljanje rizikom u IKT sistemu: Menadţment se obavezuje da
obezbedi rentabilne mere zaštite, proporcionalne faktorima pretnji i
ranjivostima objekata IKT sistema.
Zaštita mreže i Interneta: Kada projektuje i implementira sistem zaštite
raĉunarske mreţe organizacije, menadţment se obavezuje da razmatra
potencijalni uticaj pretnji sa globalne mreţe (Interneta) i drugih
povezanih javnih mreţa.
Normativni, administrativni i ugovorni zahtevi u sistemu zaštite:
Menadţment se obavezuje da upozna i preduzmu sve mere da sistem
zaštite obuhvati sve normativne, administrativne i ugovorne zahteve koji
postoje za IKT objekte.
Etički principi: Menadţment se obavezuje da poštuje prava i
dostojanstvo pojedinaca u procesima definisanja politike zaštite,
selekcije, implementacije i nametanja mera i metoda zaštite.

- 61 -
2.5. Potpuni principi zaštite

Potpune (detaljne, kompletirane) principe zaštite definišu do

detalja i izraĊuju specijalisti zaštite, naglašavajući specifiĉne aktivnosti
koje treba obuhvatiti u dnevnom upravljanju rizikom i sistemom zaštite.
Osnovni elementi su instrukcije korak-po-korak ili procedure zaštite,
koje su neophodne da se realizuju odgovarajući taktiĉki ciljevi
funkcionalnih principa i strateški ciljevi opštih principa zaštite. Detaljni
principi zaštite ĉesto se menjaju u skladu sa promenama tehnologije i
komponenti sistema zaštite. Obuhvataju metod usaglašavanja sa
funkcionalnim principima zaštite, u odnosu na postojeće okruţenje,
pretnje i raspoloţivu tehnologiju. Sadrţe detaljnija objašnjenja principa,
koji podrţavaju jedan ili više funkcionalnih principa zaštite. Potpuni
principi zaštite obuhvataju razliĉite tehnologije, okruţenja, standarde,
praksu zaštite i koncepte koji su relevantni za funkcionalne principe
zaštite, neprekidno ukljuĉujući nove tehnologije i pretnje.

Primer: Potpun princip kontrole pristupa, koji podrţava funkcionalni

princip - Kontrolu pristupa, a koji sa svoje strane podrţava Opšti princip
– Proporcionalnosti.
Princip: Koristiti jednokratne pasvorde za logiĉku kontrolu pristupa
svim informacijama koje se smatraju kritiĉnim za organizaciju.
Objašnjenje: Višestruko korišćeni pasvordi su tradicionalno jedina
tehnika na raspolaganju za kontrolu pristupa objektima IKT sistema.
Tehnološke promene uĉinile su pasvorde za višekratnu upotrebu
zastarelim u mnogim primenama. Zbog toga se uvodi pasvord za
jednokratnu upotrebu. Savremena tehnologija smart kartica sve više
potiskuje tekuću tehnologiju pasvorda za kontrolu pristupa IKT sistemu i
autentifikaciju korisnika.

- 62 -
3. REZIME

Konzistentni principi zaštite informacija i IKT sistema, osnovni

su gradivni elementi na kojima se zasnivaju procesi upravljanja sistemom
zaštite, a u širem smislu ukljuĉuju principe, standarde, konvencije i
mehanizme zaštite. Glavni principi odnose se na - upravljanje,
funkcionalni – na operativno upravljanje, a kompletirani (detaljni) - na
praksu zaštite i specijaliste zaštite.

Opšti principi usmeravaju upravljaĉku strukturu na izvršnom nivou,

obuhvaćeni su uputstvima na visokom nivou i pomaţu organizaciji da
definiše efektivnu strategiju zaštite. Namenjeni su za upravljanje
sistemom zaštite, fundamentalni su i retko se menjaju. Ovi principi
obuhvataju integrisane OECD i NIST kljuĉne atribute zaštite
raspoloţivosti, integriteta i poverljivosti informacija, a sadrţe 9 principa
(odgovornosti, preispitivanja i procene, svesti o potrebi zaštite, etiĉnosti,
demokratiĉnosti, integracije, multidisciplinarnosti, proporcionalnosti i
blagovremenosti).

Funkcionalni principi zaštite su gradivni blokovi opštih principa i sa

perspektive upravljanja detaljnije definišu preporuĉenu taktiku izgradnje
efektivne arhitekture sistema zaštite.

Kompletirani, detaljni principi zaštite koriste funkcionalne principe kao

okvir. Namenjeni su za profesionalce u sistemu zaštite, obezbeĊuju
specifiĉno, sveobuhvatno uputstvo za dnevne aktivnosti u procesu
upravljanja rizikom i sistemom zaštite u IKT.

- 63 -
4. KLJUĈNI TERMINI

Funkcionalni GAISP principi zaštite: detaljnije definišu taktiku

izgradnje efektivne arhitekture sistema zaštite, gradivni blokovi opštih
principa.
GAISP principi zaštite: sveobuhvatna hijerarhija instrukcija i uputstava
za obezbeĊenje opšte prihvaćenog, konzistentnog, praktiĉnog okvira za
zaštitu informacija, koji u odreĊenim sluĉajevima mogu imati izuzetak.
Digitalni objekti: fiziĉki i logiĉki objekti IKT sistema koji obraĊuju,
prenose i skladište digitalne podatke; sinonim - informatiĉki objekt.
Kompletirani GAISP principi zaštite: obezbeĊuju specifiĉna,
sveobuhvatna uputstva za dnevne aktivnosti u procesu upravljanja
rizikom i sistemom IKT zaštite; gradivni blokovi funkcionalnih principa.
Opšti GAISP principi: usmeravaju menadţment na izvršnom nivou,
obuhvataju smernice i pomaţu organizaciji da definiše efektivnu
strategiju zaštite.
Opšti principi zaštite: namenjeni za upravljanje sistemom zaštite,
fundamentalni su i retko se menjaju; obuhvataju kljuĉne atribute zaštite
raspoloţivosti, integriteta i poverljivosti informacija; sadrţe 9 principa
(odgovornosti, preispitivanja i procene, svesti o potrebi, etiĉnosti,
demokratiĉnosti, integracije, multidisciplinarnosti, proporcionalnosti i
blagovremenosti).
Princip: (zaštite) fundamentalna istina, ili zakonitost koja se uzima bez
dokazivanja kao osnova za izvršavanje racionalne aktivnosti u procesu
realizacije nekog koncepta (sistema zaštite).

- 64 -
5. LITERATURA
1. British Standards Institution, BS 7799-2—Code of Practice for
Information Security Management, http://www.bsi.org,
http://www.iso.org, 1999.
2. GAISP – Generally Accepted Information Security Principles,
http://www.gaisp.org, 2003.
3. http://www. isecom.org/projects/osstmm.htm
4. http://www.cve.mitre.org.
5. IETF Policy Framework, http://www.ietf.org,
6. Introduction to the OCTAVE®Approach,
http://www.cert.org/octave
7. ISF – The Standard for Good Practice for Information Security,
http://www.isf.org, 2003.
8. ISO 17799 - Code of Practice for Information Security
Management, http://www.iso.org, 2000.
9. ISO/IEEC 13335, Guidelines for the Management of IT Security,
http://www.iso.org, 2000.
10. ISO/IEEC 15408, Common Criteria/ITSEC,
http://www.itl.nist.gov/.
11. IT Governance Institute, COBIT (Control Objectives for
rd
Information and related Technology), 3 Edition,
http://www.ITgovernance.org and http://www.isaca.org, 2000.
12. NIST SP 800-12, An Introduction to Computer Security- The
NIST Handbook, http://csrc.nist.gov/publications/nistpubs/800-
12/sp800-12.pdf, septembar 2003.
13. NIST SP 800-14, Generally Accepted Principles and Practices
for Security, http://csrc.nist.gov/publications/nistpubs/800-
14/sp800-14.pdf, 1999.
14. NIST SP 800-18, Guide for developing Security Plans for IT
Systems, http://csrc.nist.gov/publications/nistpubs/800-18/sp800-
18.pdf, 2003.
15. NIST SP 800-53, Recommended Security Controls For Federal
IS, http://csrc.nist.gov/publications/nistpubs/800-53/sp800-53.pdf,
2004.
16. OECD - Guidelines for the Security of Information Systems and
Networks, http://www.oecd.org, 2000.
17. Petrović R.S., Ćirić V., Zaštita podataka u automatizovanim
informacionim sistemima, Nauĉna knjiga, Beograd, 1986.

- 65 -
18. RFC 2196 Site Security Handbook
http://www.ietf.org/rfc/rfc2196.txt, 1997.

- 66 -
5. NORMATIVNI OKVIR I STANDARDI ZAŠTITE

0. UVOD

Kada završite ovo poglavlje razumećete:

- značaj standarda i standardizacije oblasti zaštite

- podelu na interne i eksterne (industrijske) standarde
- ključne standarde za upravljanje zaštitom (IEC/ISO 17799...)
- ključne standarde za sistem kvaliteta zaštite (SSE CMM,...)

Kompleksni sistem zaštite svetskog kibernetiĉkog prostora,

ukljuĉuje raznovrsne nacionalne zakonske okvire, pravosudne sisteme,
standarde, operativne i ugovorne zahteve, praksu zaštite i razliĉite
tehnologije zaštite. Otuda je nuţna i potrebna kooperacije svih delova
sistema za harmonizaciju relevantnih faktora sistema zaštite, a zakoni i
standardi zaštite predstavljaju najznaĉajniju komponentu te
harmonizacije.

Normativni okvir (Zakoni i podzakonska akta u oblasti zaštite) i

standardi zaštite ĉine metodološku osnovu na kojoj se izraĊuju
dokumenata programa zaštite, a nastaju na više nivoa: meĎunarodnom
nivou, kao što su industrijski (eksterni), brojni šire prihvaćeni standardi
zaštite, npr. ISO/IEC 17799, ISO 15408 (CC), ISO/IEC 21827 (SSE
CMM) i dr., državnom, nacionalni Zakoni o zaštiti podataka i
informacija, Zakon o elektronskom potpisu, Zakon o borbi protiv visoko
tehnološkog kriminala i dr.; administrativnom, razne uredbe, propisi,
pravilnici (npr. Pravilnik o uspostavljanju sertifikacionog tela) i na nivou
organizacije interni standardi zaštite, kao što su dokumenta programa
zaštite - plan zaštite, politike zaštite, procedure zaštite, uputstva za
zaštitu, ugovori, sporazumi, dnevnici rada, propisi, radna dokumenta
i.t.d.

Zakoni i podzakonska akta u oblasti zaštite obezbeĊuju osnovni okvir za

šire uspostavljanje i implementaciju programa zaštite IKT sistema u
organizacijama, kao i mehanizme sankcionisanja koji predstavljaju i
faktore motivacije da se ovi zakoni sprovode.

- 67 -
Standardi zaštite obezbeĊuju pravila upravljanja sistemom zaštite, a
mogu se izvoditi iz normativa (zakona) i regulatornih propisa ili
industrijske prakse i iskustava, kao što su standardi najbolje prakse
zaštite. Standardi zaštite pomaţu korisnicima da prevedu (kodiraju)
zahteve za zaštitu sa nivoa normativa (zakona) u bezbednosne zahteve na
nivou politika zaštite.

Uputstva za zaštitu su precizne instrukcije za upravljanje sistemom

zaštite, koje ne obavezuju korisnike da ih striktno sprovode za razliku od
zakona i standarda zaštite.

- 68 -
1. NORMATIVNI OKVIR ZAŠTITE

Normativni okvir je vaţan jer obezbeĊuje znaĉajne funkcije, kao

što su: isticanje znaĉaja problematike zaštite informacija na najvišem
drţavnom nivou, koncentrisanje resursa na najznaĉajnijim, strateškim
pravcima istraţivanja i razvoja, koordinacija obuke i obrazovanja,
sankcionisanje zloupotreba IKT sistema i narušavanja sistema zaštite,
obaveza sertifikacije i akreditacije sistema zaštite i dr. U normativnom
okviru posebno mesto zasluţuju podzakonski pravni akti (n.p.r.
Pravilnici o uspostavljanju PKI, CA i digitalnog potpisa u Zakonu o
elektronskom potpisu) i standardi zaštite, [25], [18] .

Na nivou svake drţave treba i uglavnom postoji Zakon o zaštiti

informacija u IKT okruţenju, koji obavezuje pojedince i poslovne
subjekte da štite svoje informacije i IKT sisteme, propisuju obavezan
obim te zaštite, od ĉega treba informacije štititi, kako štititi privatnost i
poverljivost korisnika i kakve su sankcije za povrede sistema zaštite,
[23], [24]. Zakoni o zaštiti predstavljaju prvi nivo kodiranja
kulturoloških i socioloških karakteristika društva u upravljaĉke kontrole
na najvišem nivou drţave. Pored zakona o zaštiti informacija u IKT
okruţenju, na nivou drţave donose se i potrebni su brojni zakoni koji
regulišu kompjuterski kriminal (Zakon o kompjuterskom kriminalu,
Zakon o digitalnom dokazu, Zakon o sudskom veštaĉenju u oblasti IKT,
Zakon o formiranju CIRT – Computer Incident Response Team na
nacionalnom nivou i dr.), [5], [6]. Globalni karakter zloupotreba i
kompjuterskog kriminala, kao i sve veća umreţenost intranet RM
(poverljivih LAN) u Internet okruţenju, zahtevaju da se u procesu
dokumentovanja i razvoja programa zaštite - plana, politike i procedura
zaštite razmatraju i implementiraju brojni zakonski okviri: usklaĎenost sa
meĊunarodnim zakonom, regulativama i standardima; razlike
pravosudnih sistema u zakonima i regulativi; ugovorne obaveze i obaveze
o čuvanju poslovnih tajni i zaštita privatnosti i ličnih podataka.

Zahtev za usklaĎenost zakona, regulativa i standarda zaštite na

meĊunarodnom nivou nameću sve veća globalizacija primena IKT i
porasta transnacionalnog kompjuterskog kriminala. U razvoju svakog
programa zaštite treba ukljuĉiti nacionalni zakonski okvir koji reguliše
tip podataka kojima se pristupa, naĉine korišćenja, skladištenja ili
procesiranja u IS organizacije i identifikovati sve primenljive normativne
zahteve.

- 69 -
Razlike u pravosudnim sistemima izmeĊu pojedinih drţava, posebno
dolaze do izraţaja u sluĉaju transnacionalnog prenosa i zloupotrebe
podataka (na primer, istraga sluĉaja ekonomske špijunaţe gde jedan
pravosudni sistem štiti, a drugi ne isti tip podataka i informacija). Ĉesto
se podaci u svom ţivotnom ciklusu kreću izmeĊu nekoliko lokacija, pa je
vaţno pratiti izvor podataka i da li su zaštićeni na tom putu. TakoĊe,
legalni zahtev provajderima Internet i komunikacionih usluga za
zadrţavanje podataka za potrebe policije i bezbednosnih sluţbi, varira od
drţave do drţave. Posebno se zahteva zaštita privatnosti podataka u
periodu njihovog zadrţavanja. EU je usvojila Direktivu (25.07.2002.) o
privatnosti i elektronskim komunikacijama zahtevajući od provajdera da
zadrţavaju saobraćaj i lociraju podatke na svim komunikacijama preko
mobilnih telefona, faksova, e-mail i drugih komunikacija. Dakle,
programi zaštite u zemljama EU moraju obezbediti adekvatno
zadržavanje i zaštitu privatnosti podataka u zakonskom periodu
zadržavanja. Autorska prava moraju biti zaštićena sa programom zaštite
na naĉin koji zadovoljava legalne zahteve, [2].

U mnogim zemljama Zakon o borbi protiv kompjuterskog kriminala je

neadekvatan i ne pokriva kriminalne aktivnosti koje su po svojoj prirodi
transnacionalne, a moraju se istraţivati, dokazivati i sankcionisati
usklaĊenim i standardizovanim procedurama i alatima u svim
zainteresovanim pravosudnim sistemima.

Ugovori i ugovori o neotkrivanju poslovnih tajni – NDA (Non Disclose

Agreement) moraju na isti naĉin tretirati vlastite i IKT objekte druge
organizacije – ugovorne strane, što ĉesto nije sluĉaj. Da bi se informacije
zaštitile od neovlašćenog otkrivanja, organizacije moraju imati
eksplicitnu politiku i procedure zaštite koje zadovoljavaju zahteve
zakona o kompjuterskom kriminalu o neotkrivanju poslovnih tajni u
konkretnom pravosudnom sistemu.

Poverljive informacije i informacije o intelektualnoj svojini, program

zaštite mora štititi na naĉin koji zadovoljava minimalne zahteve zakona o
zaštiti informacija i poslovnih tajni, da bi se moglo obezbediti zakonsko
gonjenje poĉinioca u pravosudnom sistemu gde se kriminal dogodio.

- 70 -
Zaštita privatnosti i ličnih podataka u mnogim pravosudnim sistemima,
nema kompletirane i sa zakonima EU usaglašene zakonske regulative,
uprkos velikom pritisku javnosti. Preporuke da se privatnost i liĉni
podaci štite opštim i tehniĉkim merama zaštite, ostavljaju prostor za
proizvoljnost i uvek su jeftinije za svaku organizaciju, nego obavezna
zaštita propisana zakonom.

- 71 -
2. STANDARDI ZAŠTITE

Standardi postoje za komponente sistema i sisteme zaštite IKT,

kao i za organizacije koje se bave zaštitom IKT sistema. Na taj naĉin i
organizacije i proizvodi zaštite mogu biti sertifikovani i akreditovani da
zadovoljavaju odreĊene standarde. Standarde donose brojna
meĊunarodna akreditovana tela. Standarde zaštite donosi Komitet za
standardizaciju JTC1/SC27. U PRILOGU I 5A dat je pregled
meĊunarodnih tela za standardizaciju u oblasti zaštite IKT sistema,
pregled radnih grupa i lista izdatih standarda komiteta za standardizaciju
zaštite [ISO/IEC JTC1/SC27], a u PRILOGU I 5B referentna lista
publikacija ISO/IEC/JTC 1/SC 27 komiteta za standarde i nacrta
standarda za IKT tehnike zaštite.

Primarni cilj standarda zaštite nije sama standardizacija zaštite, koja bi se

mogla i zloupotrebljavati. Naime, potpuno standardizovana zaštita
sigurno bi izazvala znatno veći broj napada i pokušaja proboja, što bi
moglo ugroziti i sam koncept zaštite. Osnovne prednosti standardizacije
zaštite IKT sistema su: smanjenje kompleksnosti sistema zaštite u procesu
upravljanja, mogućnost izbora i izrade standardne dokumentacije,
obezbeĊenje interoperabilnosti sistema zaštite i formiranje svojevrsne
baze znanja iz oblasti zaštite, [1], [4], [7], [11], [14] i.t.d..

TakoĊe, standardi zaštite nezamenljivi su u procesima sertifikacije i

akreditacije sistema zaštite.
Brojni standardi obezbeĊuju osetljive metode i definišu najbolju
korisniĉku praksu, ĉak i bez procesa sertifikacije, koji ĉesto zahteva
mnogo rada i napora, a donosi malo koristi.

Standardi zaštite uvode promene u upravljaĉki okvir sistema zaštite, dok

uputstva za zaštitu obezbeĊuju neophodne detalje za praksu zaštite, koji
nisu obuhvaćeni standardima zaštite i ne unose promene u upravljaĉki
okvir.

- 72 -
2.1. Opšta definicija standarda zaštite

Standard zaštite je usvojen i objavljen dokument koji uspostavlja

specifikaciju i procedure dizajnirane da obezbede da dokumenta,
materijal, proizvod, metod ili servis zaštite odgovara njegovoj nameni i
konzistentno izvršava svoje predviĎene funkcije. U praksi standard zaštite
sadrţi ĉitav set aranţmana za pokrivanje svih (ili što većeg broja)
bezbednosnih zahteva za odrţavanje rizika na prihvatljivom nivou. U
oblasti zaštite, standardi obezbeĊuju objektivne mere na koje se inţenjeri,
konstruktori i prodavci mogu osloniti u razvoju i implementaciji sistema
za zaštitu. Standard je glavni alat za poboljšanje kvaliteta i efikasnosti
kontrola zaštite apliciranih u IKT sistemu organizacije. Standard zaštite
se u organizaciji moţe koristiti za: povećanje nivoa bezbednosti i zaštite,
integrisanjem delova standarda u poslovne procese; procenu kvaliteta
sistema zaštite; izbor kontrola sistema zaštite; poboljšanje programa
obrazovanja, obuke i podizanja svesti o potrebi zaštite i dr.

Bitni atributi kvaliteta svakog standarda su, da je: dokumentovan,

raspoloživ, izdat od strane prihvaćenog nacionalnog tela za
standardizaciju, adekvatan nameni, rentabilan (Cost-benefit),
dobrovoljno prihvaćen, okvir i obezbeĎuje benčmarking, usaglašen sa
zakonima i meĎunarodnim ugovorima, sveobuhvatan (tehnološke,
procesne, ljudske aspekte aktivnosti), [22].

- 73 -
2.2. Opšti model standarda za upravljanje zaštitom

Opšti, piramidalni, hijerarhijski model standarda za upravljanje

IKT zaštitom obuhvata: terminologiju, principe, metodologiju (okvir,
metod), elemente standarda, uputstvo za primenu i dodatke, tehnike i
alate (Sl. 2.1). Terminologija navodi listu definicija, pojmova i termina.
Principi obezbeĊuju generalno prihvatljiva pravila na visokom nivou,
koja se aksiomatski koriste kao osnova za izradu uputstava zaštite.
Metodologija (okviri ili metodi) obezbeĊuje pojednostavljen opis naĉina
korišćenja koncepta, metoda i tehnika i njihovih meĊusobnih odnosa u
organizaciji. Elementi standarda obezbeĊuju specifiĉne zahteve koji se
primenjuju na definisanu oblast upravljanja zaštitom. Uputstvo za
primenu obezbeĊuje detaljan opis i daju uputstva o tome kako se
elementi standarda mogu primeniti u specifiĉnim situacijama, [18].

TERMINOLOGIJA
PRINCIPI
METODOLOGIJE (OKVIRI)

STANDARDNI ELEMENTI

UPUTSVO ZA APLIKACIJE I DODACI

TEHNIKE I ALATI

Sl. 2.1. Opšti model standarda za upravljanja IKT zaštitom

- 74 -
2.3. Klasifikacija standarda zaštite

U opštem sluĉaju uobiĉajena klasifikacija standarda zaštite je na

eksterne i interne (Sl. 2.2.), [22].

Standardi

Eksterni standardi Interni standardi

(primer: ITU X.509)

Specifikacioni Proceduralni
standardi standardi

(primer: Windows (primer: procedura

XP konfiguracija) administracije Win XP)

Sl. 2.2. Klasifikacija standarda zaštite

Eksterni (industrijski) standardi, razvijeni i šire prihvaćeni, namenjeni

su (ali ne samo) za:
upravljanje sistemom zaštite, analizu rizika, obuku, evaluaciju sistema i
proizvoda zaštite i
sertifikaciju i akreditaciju.

Prednosti eksternih standarda u odnosu na interno razvijene su što

obezbeĊuju: više testiranja softvera zaštite koji implementiraju ove
standarde u praksi, lakše otkrivanje i brţe fiksiranje bezbednosnih
problema i brţu razmenu iskustva iz prakse zaštite.

- 75 -
Eksterne standarde zaštite periodiĉno treba usaglašavati sa kriterijumima
za razvoj programa zaštite i projektovanje sistema zaštite (Tabela 2.1).

Kriterijumi za razvoj
programa i projektovanje
sistema zaštite
1 Pokrivanje kljuĉnih pitanja
2 Kompletnost
Ukljuĉivanje poslednjih
3 tehnoloških rešenja razvoja i
„vrućih sadrţaja―
Posedovanje lako razumljive
4
strukture i kompozicije
5 Razumljivost i nedvosmislenost
ObezbeĊuje dovoljno praktiĉnih
6
detalja
ObezbeĊuje stepen
7 primenljivosti na svaku
organizaciju
8 Praktiĉna dostupnost
9 Merljivost performansi
10 Lakoća korišćenja
Usaglašenost Standarda sa kriterijumima
Obuhvata sve komponente bezbednosti IS sa 5
samostalnih aspekata (upravljanje zaštitom, kritiĉne
operacije, instalacije raĉunara, raĉunarske mreţe i razvoj
sistema zaštite)
Iscrpno pokriva sve glavne bezbednosne kategorije IS i
konzistentan i ravnopravan u pogledu detalja koje nudi
Aţuriranje i ukljuĉivanje poslednjih tehnoloških rešenja
vrši se svake dve godine
Tabelarno predstavljanje uz podršku unakrsnih referenci
i indeksa
Koristi jednostavan reĉnik i prihvaćene tehniĉke termine,
recenzirane od strane ISF (Information Security Forum)
ObezbeĊuje konzistentan nivo detalja koji formiraju
bazu za lake i direktne aplikacije
Projektovana za velike organizacije, jednako se
primenjuje na poslovne jedinice, kao i male i srednje
organizacije.
Set dokazanih dostiţnih ciljeva, koje svaka organizacija
treba da moţe dostići
Izraţen je na naĉin koji merenje performansi ĉini
jednostavnim i direktnim
Projektovan i dat u formatu koji koristi jednostavan
brojni sistem, koje profesionalci iz zaštite i sa
minimalnim iskustvom mogu lako primeniti u praksi

Tabela 2.1. Mera usaglašenosti standarda sa kriterijumima za razvoj

sistema zaštite

U praksi zaštite najĉešće korišćeni eksterni standardi su tzv. standardi

najbolje (dobre) prakse zaštite (ISO/IEC 17799; NIST; ISF v.4.0,

- 76 -
2003), koji obuhvataju set empirijski potvrĊenih principa zaštite
skupljenih širom sveta.

Interni standardi su specifiĉni su za organizaciju koja ih proizvodi,

predstavljaju jezgro za formiranje okvira za upravljanje sistemom zaštite,
dodaju novu vrednost i pomaţu kod interpretacije politika zaštite. Mogu
se klasifikovati na: specifikacione i proceduralne standarde.

Specifikacioni interni standardi definišu sistem osnovne zaštite

(optimalan, idealan) za datu konfiguraciju IKT sistema. Svaka
organizacija definiše ovaj standard na bazi teoretskih razmatranja i izbora
osnovnih kontrola zaštite (eng. baseline) iz kataloga kontrola za najbolju
praksu zaštite. Za izradu ovakvog standarda za veći IKT sistem (na
primer, visoko distribuirani u Internet okruţenju, sa oko 2000 radnih
stanica, 200 raznih servera) potrebno je oko 6 meseci rada. Ovaj sistem
osnovnih kontrola zaštite mora se u fazi razvoja i implementacije
dopuniti sa novim kontrolama zaštite specifiĉnih za sistem i okruţenje, a
na bazi rezultata analize rizika.

Proceduralni interni standardi su korisni mehanizmi za opisivanje

procedura za administraciju zaštite i treba da ukljuĉuju samo vaţne
korake bez tehniĉkih detalja. Uglavnom su generiĉki i nisu specifiĉne za
IS (platformu). Detalji se opisuju u tehniĉkoj dokumentaciji za
ureĊaje/sisteme.

- 77 -
2.4. Prednosti i nedostaci standarda zaštite

Osnovne prednosti standardizacije oblasti zaštite IKT sistema su

smanjenje kompleksnosti sistema zaštite, izbor i izrada standardne
dokumentacije i obezbeĊenje interoperabilnosti sistema i organizacija
širom sveta.Osnovni nedostatak standardizacije zaštite je što ne postoji
integralni standard za upravljanje zaštitom, tipa opšte prihvaćenog
standarda najbolje prakse zaštite za upravljanje sistemom zaštite (tipa
ISO /IEC 17799), koji bi pored odgovora ŠTA treba uraditi u zaštiti, dao
instrukcije KAKO to treba uraditi (tipa ISO/IEC 21827, 2001, SSE
CMM-System Security Engineering Capability Maturity Model, v. 3,
2003). MeĊutim, zbog prirode koncepta zaštite, verovatno je dobro da se
takvi standardi nikada ni ne pojave. Naime, tako standardizovana zaštita
sigurno bi bila predmet znatno većeg broja napada i pokušaja proboja, što
bi moglo ugroziti sam koncept i napore zaštite.

Implementacija standarda i normativno usklaĊivanje, samo po sebi nije

dovoljno. Standardi , ako su konzistentno primenjeni, obezbeĊuju uslove
za visoki stepen razvoja programa zaštite i projektovanja sistema zaštite,
a normativno usklaĊivanje obezbeĊuje usmeravanje paţnje na zaštitu
specifiĉnih i osetljivih informacija. Preporuĉuje se da organizacija u
program zaštite integriše interne i eksterne standarde, najbolju praksu i
usklaĊenost sa zakonom i regulativama, da bi se izgradio sveobuhvatni
okvir za sistem merenja i evaluacije zaštite unutar organizacije.

- 78 -
2.5. Razvoj i implementacija standarda najbolje prakse zaštite

Definicija najbolje (dobre) prakse zaštite informacija je

kompleksna, raznolika i obuhvata više izvora. Moţe zahtevati
reinţenjering zaštite i zbog donošenja zakona i regulativa. Najbolja
praksa na meta nivou moţe se definisati kao: „Najbolja praksa su
dokumentovane, pristupačne, efikasne, odgovarajuće i široko prihvaćene
strategije, planovi, taktike, procesi, metodologije, aktivnosti i pristupi,
razvijeni od strane kompetentnih entiteta i izvršeni sa adekvatno
obučenim personalom, koji su u saglasnosti sa postojećim zakonima i
regulativama, koji su se vremenom potvrdili kroz istraživanje, evaluaciju
i praksu kao efikasni u obezbeĎivanju zaštite na prihvatljivom nivou
rizika i koji se neprekidno revidiraju i poboljšavaju u skladu sa
promenama okruženja, tehnologija, pretnji, organizacije i sl.―, [7].

U skladu sa ovom definicijom, program/sistem zaštite mora biti:

dokumentovan; pristupačan; povezan standardom (strategijski, taktiĉki,
baziran na procesu i metodologiji, testiran u vremenu i praksi,
obezbeĊuje zaštitu prema definisanim zahtevima); neprekidan proces
poboljšavanja (obuke, edukacije i sertifikacije); ponovljiv, efikasan i
rentabilan (korisnost je veća od troškova);
nadogradiv (skalabilan, nekoliko vitalnih i više trivijalnih komponenti);
efektivan (vodi do ţeljenog cilja); skalabilan (adaptivan i fleksibilan, da
obuhvata plan za vanredne dogaĊaje); praćen (monitorisan, obezbeĊuje
metriku); usaglašen (sa postojećim zakonima i regulativama) i
sveobuhvatan (obuhvata sve aspekte kao što su: kadrovi, procesi,
procedure, politike, planovi, sistemi, tehnologije, mreţe i mreţni objekti).

Ovaj pristup („odozgo-na dole―) definiciji najbolje prakse pomaţe u

razumevanju bitnih osnovnih i kljuĉnih atributa generiĉke dobre prakse i
elemenata vaţnih za zaštitu informacija, [7], [22].

Glavni ciljevi standarda najbolje prakse zaštite su da promovišu najbolju

praksu zaštite, poboljšaju nivo bezbednosti, smanje rizik na prihvatljiv
nivo i pomognu dalji razvoj standarda.

Namena standarda najbolje prakse zaštite je da pomogne korisnicima u

formiranju i izboru adekvatnih kontrola za najbolju praksu zaštite, koje
obezbeĊuju maksimalnu zaštitu, ali nisu uvek adekvatne za potrebe i
okruţenje konkretne organizacije. Za uspostavljanje dobro upravljivog

- 79 -
poslovnog okruţenja, gde se rizik mora drţati pod kontrolom, potrebno
je: na bazi procene rizika redefinisati kontrole IKT zaštite i izabrati one
koje daju najbolje rezultate; implementirati standard u sve faze životnog
ciklusa i upravljati promenama - odrţavati efektivan i efikasan skup
kontrola zaštite regularnom procenom rizika.

Implementacija standarda najbolje prakse IKT zaštite pomaţe

organizaciji da se: uključi u meĎunarodno prihvaćenu praksu zaštite;
upravlja rizikom, izgradi poverenje drugih entiteta, smanji štetne
posledice glavnih incidenata, uspešnije bori protiv kompjuterskog
kriminala, usklaĎuje praksu sa pravnim i normativnim zahtevima,
održava kontinuitet poslovanja i dr.

Najbolja praksa zaštite tipiĉno se implementira u program IKT zaštite uz

podršku i aktivnu saradnju menadţmenta organizacije: glavnog
menadžera, menadžera zaštite, administratora sistema, administratora i
kontrolora (eng. auditor) zaštite. Prema anketi ISF (2002) glavni faktori
za pokretanje, razvoj i implementaciju standarda za upravljanje sistemom
IKT zaštite dati po znaĉaju i uticaju prikazani su u Tabeli 2.2, [7].

- 80 -
 Faktori za pokretanje, razvoj i implementaciju
Pokretaĉi
standarda
Implementirati najbolju praksu
Evaluirati status kontrola sistema zaštite
Glavni
Postaviti temelj za pouzdan sistema zaštite
Redukovati uĉestanost/uticaj glavnih incidenata
Usaglašenost sa internom politikom zaštite organizacije
Integracija u program upravljanja rizikom organizacije
Vaţni
Ispuniti zahteve normativnog regulisanja
Maksimalno iskoristiti tekuće ulaganje u zaštitu
Dobiti konkurentnu prednost na trţištu
Ispuniti strategijske poslovne zahteve organizacije
Ostali
Uspešno odgovoriti na napade (hakeri, kriminalci i dr.)
Postići smanjenje troškova sistema zaštite do optimalnog nivoa

T. 2.2. Pokretaĉi razvoja i implementacije standarda najbolje prakse

Zahtevani izlazi standarda najbolje prakse zaštite informacija treba da

optimalno obuhvate:

1. Kontrolu pristupa (AC - logiĉku i fiziĉku) svih koji pristupaju

mreţi;
2. Raspoloživost informacija, sistema, mreţa, ureĊaja i potrebnog
personala;
3. Autentifikaciju korisnika i ureĊaja pre davanja pristupa resursima;
4. Integritet informacija, mreţa, sistema, ureĊaja i personala;
5. Poverljivost podataka i pristup podacima samo ovlašćenim
korisnicima;
6. Neporecivost izvršenih aktivnosti i mogućnost verifikacije od
strane trećeg lica i
7. Usaglašenost sa svim vaţnim zakonima i regulativama.

Otvorena pitanja iz oblasti najbolje prakse zaštite su: razliĉiti uticaji

postojećih nacionalnih zakonskih okvira; uticaj razliĉiti nacionalnih
zakona i pravnih okvira na najbolju praksu zaštite u raznim zemljama

- 81 -
jedne te iste organizacije, razliĉite i brojne definicije najbolje prakse
oteţavaju izradu primenljivog jedinstvenog modela najbolje prakse,
veliki broj sertifikacionih tela oteţava kreiranje jedinstvenog sertifikata
za najbolju praksu zaštite informacija i dr. Najpotpuniji model najbolje
prakse zaštite nalazi se u priruĉniku „Hierarchy of Security―, [22].

Za preporuku redosleda i toka aktivnosti u proceni najbolje prakse

zaštite, mudro je konsultovati profesionalce, a obezbediti je
konzistentnim:

- praćenjem i primenom definicije najbolje prakse,

- obuhvatanjem navedenih kljuĉnih atributa,
- praćenjem postizanja ţeljenih izlaznih rezultata,
- praćenjem preporuka autoritativnih tela u ovoj oblasti i
- kontrolom prakse zaštite od strane autoriteta na odgovarajućem
nivou.

ISF standard dobre prakse zaštite IS (V. 4.0, iz marta 2003) izradila je
meĊunarodna asocijacija Information Security Forum (ISF) na osnovu
priloga i saradnje više od 250 vodećih organizacija u svetu u toku
poslednjih 14 godina. Standard se aţurira svake druge godine. Najnovija
verzija standarda obuhvata: poslednja tehnološka rešenja sistema
višeslojne zaštite informacija i IS kao što su detektori upada u sistem
(Intrusion Detection Systems - IDS); mehanizmi za zaštitu privatnosti,
zaštitu podataka i informacija i e-pošte; podizanje svesti o zaštiti;
bezbedno korišćenje beţiĉnih komunikacija i PDA ureĊaja, bluetooth
tehnologiju, metodologiju i tehnologiju forenziĉke analize softvera,
raĉunara i raĉunarske mreţe (RM). Standard je teţišno usmeren na
poslovne sisteme koji prihvataju da je zaštita informacija kljuĉno pitanje
svakog posla i usaglašen je sa standardom za zaštitu ISO/IEC 17799 i
obuhvata sledeće aspekte zaštite: upravljanje, kritične operacije, RS, RM
i razvoj sistema zaštite, [7].

Za svaki aspekt, kontrole zaštite su opisane u sekcijama koje sadrţe tri

atributa: principe: zbir glavnog skupa kontrola koje treba aplicirati,
ciljeve: namena aplikacije odreĊenog skupa kontrola, kodnu oznaku
(npr. CN 1.2): brojĉani sistem za referenciranje svake posebne kontrole
sa skupom individualnih saopštenja koja definišu kontrole zaštite.
Koncept kontrola zaštite za najbolju/dobru praksu zaštite usvojile su

- 82 -
brojne organizacije u svetu. NIST standard kontrola za najbolju praksu
zaštite opisan je detaljno u literaturi, [20].

2.6. Uputstva i dokumenta zaštite

Uputstva za zaštitu i radna dokumenta namenjena su za

povećavanje razumevanja oblasti zaštite, bez uvoĊenja promena u
upravljaĉki okvir, što ih razlikuje od standard zaštite, a ĉine ih: uputstva
koja sumiraju aspekte kontrolnog okvira (administratorska, korisniĉka),
detaljnije informacije o specifiĉnim pitanjima zaštite (tehniĉka uputstva),
grafiĉke prezentacije i ĉek liste, tehniĉki bilteni za nove tehnologije
zaštite i.t.d.

- 83 -
3. ANALIZA RELEVANTNIH STANDARDA ZAŠTITE

Većina razvijenih standarda zaštite odnosi se na zaštitu IKT sistema,

a nekoliko je fokusirano na metodologije za evaluaciju kvaliteta zaštite
(assurance-bezbednosnu garanciju). Najznaĉajniji standardi zaštite su:

- ISO/IEC 17799, Code of Practice,

- ISO/IEC 15443, Information Technology-Security Techniques,
- ISO/IEC 21827 ili SSE-CMM (System Security Engineering
Capability Maturity Model) i
- ISO/IEC 15408, Evaluation Criteria for IT Security („Common
Criteria―).

3.1. Standard ISO/IEC 17799 za upravljanje zaštitom

Najšire prihvaćen standard za upravljanje zaštitom ISO/IEC

17799 sadrţi dva dela: standard prakse, namenjen da pomogne
implementaciju vlastitog sistema zaštite i BS 7799 - specifikacija zahteva
za izbor kontrola zaštite, koja pomaţe organizaciji da definiše
bezbednosne zahteve, [11].

ISO/IEC 17799 standard, nastao iz BS 7799, u suštini predstavlja

uputstvo za upravljanje i izbor kontrola zaštite sa instrukcijama šta treba
raditi u praksi zaštite, ali ne daje odgovore kako to treba uraditi. Smatra
se kao ISO 9000 za oblast bezbednosti i zaštite IKT sistema, ali nije
toliko teţak. Usvojili su ga EU, kao i Australija i Novi Zeland (AS/NZS/
ISO/IEC 17799:2000, sa kojim je zamenjen stari AS/NZS 4444). U
većini razvijenih zemalja u svetu usvojeni su nacionalni ekvivalenti ovog
standarda, izuzev Severne Amerike. Drugi deo BS 7799 standarda
obuhvata implementaciju upravljaĉkih, operativnih i tehniĉkih (U, O, T)
kontrola zaštite koje mogu biti: politike, procedure, operativna praksa,
organizaciona struktura, ili softversko-hardverske funkcije. Kontrole
zaštite u standardu ISO/IEC 17799 definisane su u imperativu. Standard
sugeriše koje kontrole zaštite treba ukljuĉiti u program zaštite, ali ne
specificira kako ih treba razviti, implementirati i administrirati. Ovo nije
tehnički standard niti zavisi od specifične tehnologije. Ne obezbeĊuje
nikakvu metriku za evaluaciju zaštite, ali je kompatibilan i poziva se na
sistem bezbednosnih nivoa (EAL) zajedniĉkih kriterijuma za evaluaciju i
moţe se kombinovati sa metrikom SSE CMM modela.

- 84 -
ISO/IEC 17799 standard obavezuje da se kontrole zaštite biraju na
osnovu: procene rizika, normativnih okvira i specifiĉnih principa, ciljeva
i zahteva zaštite konkretne organizacije, ali ne obezbeĊuje metodologiju
za procenu rizika, kao ni uputstvo za kreiranje i ĉuvanje neophodnih
podataka za pravosudne i forenziĉke potrebe, osim uputstva za zaštitu
evidencija organizacije. Standard usmerava veliku paţnju na definisanje
politike zaštite na nivou organizacije sa instrukcijom šta dokument treba
da sadrţi, ali ne nudi detalje kako se ta politika razvija i izraĊuje. U
raspoloţivim bazama znanja na Internetu ima dosta sugestija i uzoraka
politika zaštite, ali ne i konkretnih dokumenata politike zaštite. Osnovne
karakteristike standarda date su u Tabeli T. 3.1.

10 glavnih poglavlja, 36 bezbednosnih ciljeva, 127 glavnih kontrola zaštite,

Struktura
nekoliko hiljada uputstava i instrukcija
Politika zaštite, Organizacija zaštite, Klasifikacija i kontrola objekata (IKT
sistema) zaštite, Personalna zaštita, Fiziĉka zaštita i zaštita okruţenja,
Poglavlja
Operativno upravljanje, Kontrola pristupa, Razvoj sistema i odrţavanje,
Upravljanje nastavljanjem poslovanja, Usaglašenost.
Politika zaštite, Organizacija zaštite, Klasifikacija i kontrola objekata sistema
(razmeštaj objekata infrastrukture, snabdevanje strujom, kabliranje,
Bezbednosni
odrţavanje, izdvojeni objekti, odlaganje i ponovno korišćenje informacionih
ciljevi
objekata), Personalna zaštita, Fiziĉka zaštita i zaštita okruţenja (bezbedna
(oblasti
zona, zaštita opreme IKT sistema, opšta kontrola fiziĉkog pristupa),
zaštite)
Operativno upravljanje, Kontrola pristupa, Razvoj sistema i odrţavanje,
Upravljanje nastavljanjem poslovanja, Usaglašenost.

T. 3.1. Osnovne karakteristike standarda ISO/IEC 17799

ISO/IEC 17799 (2. Deo, preuzeti BS 7799) je i katalog dobre prakse

zaštite koju treba izvršiti i specificira instrukcije za sistem upravljanja
zaštitom informacija (ISMS). Sa ISMS organizacija moţe monitorisati i
kontrolisati zaštitu informacija u cilju smanjenja rizika na prihvatljivi
nivo i obezbediti da sistem zaštite ispunjava sve normativne i zahteve
organizacije. Zahtevi za sistem upravljanja zaštitom (ISMS) obuhvataju:
Obim, Politiku zaštite, Analizu rizika, Izjavu o primenljivosti, Sistem
upravljanja razvojem/održavanjem zaštite i Dokumentaciju zaštite.

- 85 -
U standardima ISO/IEC 17799 i BS 7799-2. deo usaglašene su (2002.g.)
sledeće oblasti (T.3.2) : Politika zaštite, Analiza rizika, Izjava o
primenljivosti i Sistem upravljanja.

Obim, Poverljivost, Integritet, Raspoloţivost, Kontrolisana

Politika
odgovornost, Klasifikacija objekata zaštite, Analiza rizika,
zaštite
Normativno/regulativni okvir
Analiza Procenu vrednosti (osetljivosti) objekata IKT sistema,
rizika Procenu pretnji, Procenu ranjivosti i Procenu uticaja faktora rizika.
Identifikovanje aktuelnih kontrola zaštite, Razmatranje svih
Izjava o kontrola zaštite (128), ukljuĉujući ili iskljuĉujući neke od njih na
primenljivosti osnovu preliminarne procene, Izbor primenljivih kontrola zaštite
na osnovu analize rizika za poslovanje organizacije i informacije.
Regularne kontrolne liste koje kontrolišu da su: Kontrole
Upravljanje zaštite - na svom mestu i efektivne,
zaštitom Preostali rizik - na prihvatljivom nivou i Procene vrednosti
objekata, pretnji i ranjivosti – validne.

T. 3.2. Usaglašene oblasti u standardima ISO/IEC 17799 i BS 7799-2.

- 86 -
3.2. Relevantni standardi za evaluaciju sistema zaštite

Postoji više metodologija za testiranje i garanciju kvaliteta, koje

mogu doprineti proizvodnji bezbednih (bez bagova) programskih
kôdova. Bez proteţiranja bilo koje od tih metodologija, paţnju zasluţuje
SSE-CMM (System Security Engineering Capability Maturity Model)
model i metod. U Standardu ISO/IEC 15443 navedene su sve metode i
sredstva za kontrolu kvaliteta i to bazirane na: procesnom pristupu (SSE-
CMM, ISO 9000-3, ISO 9001, ISO/IEC 15504 i.t.d.), pristupima
proizvod/sistem/servis (CC/CEM, ITSEC/ITSEM, TCSEC/TPEP,
ISO/IEC 9646, ISO/IEC 14598 i dr.) i na pristupu okruženju (TCMM,
ISO 13407 i dr.), [9].

3.2.1. Opšti kriterijumi za evaluaciju proizvoda zaštite

Standard opštih kriterijuma-CC (Common Criteria), ISO 15408,

[8], za evaluaciju proizvoda i sistema zaštite, izradio je konzorcijum
NSA (Nacionalnih agencija za bezbednost, SAD) i EU. Pod uticajem
MeĊunarodnog komiteta, CC standard je usvojen kao meĊunarodni
standard ISO 15408. Standard su usvojile sve zemlje EU, Australija,
Japan i Rusija. Standard je zamenio postojeće standarde „Orange Book―
(SAD) i ITSEC (EU). Pregled standarda za sistem kvaliteta zaštite,
ukljuĉujući komparativnu analizu standarda CC za evaluaciju proizvoda i
sistema zaštite i ITSEC standarda, dat je u PRILOGU I 5C.

Standard CC sadrţi tri dela: Uvod i opšti model, Funkcionalni zahtevi i

Bezbednosni zahtevi. U CC standard ukljuĉeni su sledeći relevantni
standardi:

1. Procedure za registraciju profila zaštite (IS 15292),

2. Okvir za bezbednosnu garanciju (WD 15443),
3. Uputstvo za izradu profila zaštite (WD 15446) i
4. Metodologija za evaluaciju zaštite (WD 18045).

Značaj CC i ITSEC standarda, je što podiţu nivo i pouzdanost funkcija

zaštite koje su implementirane u standardnim proizvodima zaštite (OS,
bazama podataka, barijerama, ruterima IDS/IPS i dr.). CC standard nema
veću primenu, iako je dosta fleksibilan, jer ima veoma kompleksan
proces evaluacije i zahteva mnogo vremena. U svetu postoji ograniĉen
broj odobrenih tela i kapaciteta za evaluaciju po ovom standardu, ĉije su

- 87 -
usluge skupe i nefleksibilne su za transnacionalnu primenu. Organizacije
se radije odluĉuju da ulaţu novac na poboljšanje procesa zaštite, nego na
njihovu evaluaciju. Standard je znaĉajan za glavne snabdevaĉe proizvoda
zaštite i sistema smart kartica, kao i za visoko riziĉne IKT sisteme
drţavnih organa.

3.2.2. SSE-CMM model i metod

Generiĉki model CCM razvio je Software Engineering Institute

(SEI), Carnegie Mellon University (SAD), kao razvojni projekat na
inicijativu NSA (1993-96). Dok je CMM usmeren na aktivnosti i
procese upravljanja i organizacije, model progresivnog sazrevanja
kapaciteta iz oblasti sistemskog inţenjerstva u IKT zaštiti (SSE-CMM)
sadrţi skup oblasti inženjerskih organizacionih i upravljačkih procesa
zaštite. SSE CMM v. 2 postaje 2001. godine ISO standard ISO/IEC
21827 (EOS, 2001). SSE CMM v. 3 objavljena je juna 2003, [12].

SSE-CMM u nekim zonama poklapa se sa CC standardom za evaluaciju

proizvoda i sistema zaštite. SSE CMM meri zrelost i kapacitete neke
organizacije za izvršavanje procesa iz oblasti zaštite. Model pretpostavlja
da dobar metod sa zrelim procesima i kapacitetima proizvodi dobar
proizvod i sistem zaštite. SSE – CMM uvek teţi najvišem nivou
sazrevanja kapaciteta za izvršavanje procesa zaštite (Nivo 5: široko
primenjen, stalno kontrolisan i adaptivan). Model nije toliko fleksibilan
kao CC standard, ali ima dobru sistemski i procesno orijentisanu metriku.
Kako proces sazreva postaje formalno sve bolje definisan,
dokumentovan, merljiv, kontrolisan, ponovljiv i institucionalizovan
(primenjivan u celoj organizaciji), odnosno, zreliji i stabilniji. Ideja je da
što je proces zreliji postaje stabilniji, a zbog toga predvidljiviji, lakše
kontrolisan i efektivniji u pogledu troškova, produktivnosti (efektivnosti i
efikasnosti), kvaliteta i korisniĉke prihvatljivosti.

SSE CMM standard sadrţi dva dela:

a. SSE CMM-model sazrevanja, inženjerskih, upravljačkih i

organizacionih oblasti procesa (OP) i ne preporuĉuje specifiĉnu
metodologiju, kontrole ili uputstva za zaštitu i
b. SSAM-metod evaluacije zrelosti kapaciteta ovih procesa, koji
koristi SSE CMM nivoe sazrevanja kapaciteta za procenu zrelosti
procesa, a ne kvaliteta izlaza (proizvoda) tih procesa.

- 88 -
Generalno SSE-CMM standard moţe se primeniti za: merenje
poboljšavanja zrelosti procesa zaštite, evaluaciju zrelosti kapaciteta
procesa zaštite i bezbednosnu garanciju (eng. assurance) za zrelost
procesa zaštite. Organizacija, struktura, primena i sistem merenja SSE -
CMM modela opisani su detaljnije u G. II, p. 4).

3.2.3. Standard ISO/IEC 15504

Standard ISO/IEC 15504 je kompatibilan sa CMM. ISO/IEC 15504

koristi dimenzije procesa i kapaciteta, a podrţava sve vrste procesa. Na
bazi procene specifiĉnih faza (instanci) procesa, osnovne oblasti prakse
su podeljene na: organizacione, upravljačke, inženjerske, klijentsko-
snabdevačke i procese za podršku. ISO/IEC 15504 specificira sledećih 6
nivoa kapaciteta organizacije koja izvršava razvojne procese, [10]:

1. L0: nekompletan proces

2. L1: izvršen proces
3. L2: upravljan proces
4. L3: definisan i uspostavljen proces
5. L4: kvantitativno upravljan i predvidljiv proces
6. L5: optimizovan proces

ISO/IEC 15504 je primenljiv za: samo-procenu, nezavisnu procenu,

neprekidnu procenu i diskretnu procenu. Nivo L3 odgovara ISO 9000
sertifikatu kvaliteta. Pregled ostalih relevantnih standarda, uputstava,
sertifikata i drugih resursa za evaluaciju zaštite dat je u PRILOGU I 5D.

3.2.4. Ostali relevantni standardi

Cobit (Control Objectives for Information and Related
Technology) opisuje metod nadzora i kontrole rizika, koji se javlja
korišćenjem IKT sistema za podršku poslovnih procesa. Cobit standard
je objavio ITGI (IT Governance Institute) organizacije ISACA
(Information Systems Audit and Control Association). Objavljivanjem
standarda BS 7799 i NIST Security Handbook i sami autori su napustili
Cobit standard. Sertifikacija sistema zaštite prema ovom standardu
praktiĉno se ne moţe izvršiti.
ISO/IEC TR 13335 razvijen je u dva faze, kao GMITS (Guidelines for
the Management of IT Security), a zatim je 2002. godine prerastao u
standard za upravljanje zaštitom informacija i komunikacija MICTS

- 89 -
(Management of Information and Communications Technology Security),
kao mogući kandidat za standardizaciju IKT zaštite. Te godine odluĉeno
je da se umesto termina ―IT ― u buduće koristi termin ―ICT‖, što u
standardu nije konzistentno sprovedeno. Standard opisuje procedure za
definisanje bezbednosnih ciljeva i kreiranje i implementaciju koncepata
IKT zaštite. Sadrţi dobro uputstvo za definisanje procesa IKT zaštite, ali
nema obezbeĊene sertifikacije sistema zaštite na bazi ovog standarda.

Ostali relevantni standardi u oblasti IKT zaštite ukljuĉuju:

- ITU (International Telecommunications Union) znaĉajne za

komunikacije podataka: X.25 [14], X.400 [15], X.500 [16] i
X.509 [13] široko prihvaćen u oblasti PKI;
- ANSI - Nacionalna organizacija za standardizaciju SAD, koja je
izdala brojne standarde iz oblasti zaštite, [3];
- NIST (National Institute for Standards and Technologies)
proizvodi standarde za federalnu vladu SAD, ukljuĉujući
standarde zaštite, [21]. Posebno NIST izdaje FIPS publikacije
koje su namenjene za potrebe federalne vlade i industrije SAD,
[20];
- IETF i IEEE proizvele su standarde za specifiĉne interesne
zajednice. Jedno od najznaĉajnijih tela za standardizaciju
Interneta i TCP/IP protokola je dokumentacija RFC (Request for
Comment) koju objavljuje IETF. Kljuĉni dokument RFC 1539,
[17] obezbeĊuje uvod u RFC dokumenta i reference ostalih RFC
sa detaljnijim informacijama.

- 90 -
4. REZIME

Normativni okvir obezbeĊuje pravni okvir i obavezu

organizovanja i uspostavljanja sistema zaštite informacija i IKT sistema,
kao i sankcionisanja prekršioca. Normativni nivo obezbeĊuje znaĉajne
funkcije, kao što su: isticanje znaĉaja problematike zaštite na najvišem
drţavnom nivou; koncentrisanje resursa na najznaĉajnijim, strateškim
pravcima istraţivanja; koordinacija obuke i obrazovanja; sankcionisanje
zloupotreba IKT sistema i narušavanja sistema zaštite, obaveza
sertifikacije i akreditacije sistema zaštite i dr. Podaci i informacije štite se
i ustavom, zakonom, regulativnim propisima, obiĉajnim pravom i
ugovorom izmeĊu zainteresovanih strana.

Standardi zaštite obezbeĊuju pravila upravljanja sistemom zaštite, a

mogu se izvoditi iz normativa (zakona) i regulatornih propisa ili
industrijske prakse i iskustava. Primarni cilj standarda nije sama
standardizacija neĉega, nego: smanjenje kompleksnosti sistema zaštite;
mogućnost izbora standardne dokumentacije u slučaju potrebe i
obezbeĎenje interoperabilnosti.

Eksterni industrijski standardi su brojni, na primer za: upravljanje

sistemom zaštite, analizu rizika, obuku, evaluaciju sistema i proizvoda
zaštite, sertifikaciju i akreditaciju i.t.d.
Interni standardi su specifiĉni su za organizaciju koja ih proizvodi i
predstavljaju jezgro za formiranje okvira za upravljanje; dodaju vrednost
i pomaţu interpretaciju politike zaštite. Dele se na: specifikacione (npr.,
izbor osnovnih kontrola zaštite) i proceduralne (npr., procedura za rad
administratora sistema zaštite). Uputstva za zaštitu su precizne instrukcije
za upravljanje sistemom zaštite, koje ne obavezuju korisnike da ih
striktno sprovode za razliku od zakona i standarda zaštite.

Relevantni, široko prihvaćeni standardi za upravljanje zaštitom su: BS

7799, ISO/IEC 17799 i ISO/IEC 15408 (Common Criteria), a za
evaluaciju i merenje zrelosti procesa zaštite najznaĉajniji je SSE-CMM-
v. 3, 2003, a usvojen kao ISO standard ISO/IEC 21827. Ovaj standard
je i metod za poboljšanje procesa zaštite sa većim kvalitetom i u
planiranom vremenu.

Standard dobre prakse zaštite IKT sistema (Verzija 4.0, iz marta 2003)
izradila je meĊunarodna asocijacija Information Security Forum (ISF) i

- 91 -
aţurira se svake druge godine. Najnovija verzija standarda obuhvata:
poslednja tehnološka rešenja sistema višeslojne zaštite informacija kao
što su detektori upada u sistem (Intrusion Detection Systems-IDS);
mehanizmi za zaštitu privatnosti, podataka i informacija i e-pošte; razvoj
svesti o potrebi zaštiti; korišćenje beţiĉnih komunikacija i PDA ureĊaja i
metodologiju i tehnologiju forenziĉke analize softvera, raĉunara i
raĉunarske mreţe (RM). Standard je teţišno usmeren na poslovne
sisteme koji prihvataju da je zaštita informacija kljuĉno pitanje svakog
posla, usaglašen je sa standardom za zaštitu ISO/IEC 17799 i obuhvata
sledeće oblasti: upravljanje zaštitom, kritiĉne operacije, instalacije
raĉunara, raĉunarske mreţe i razvoj sistema zaštite.

- 92 -
5. KLJUĈNI TERMINI

Eksterni standardi zaštite: nastali uglavnom izvan organizacije koja ih

koristi, šire prihvaćeni (industrijski, nacionalni, meĊunarodni) za
upravljanje sistemom zaštite, analizu rizika, obuku, evaluaciju sistema i
proizvoda zaštite, sertifikaciju i akreditaciju i.t.d.; periodiĉno se
usaglašavaju sa kriterijumima za projektovanje i razvoj sistema zaštite.
Interni standardi zaštite: specifiĉni su za organizaciju koja ih
proizvodi, jezgro za formiranje okvira za upravljanje sistemom zaštite,
dodaju vrednost IS, pomaţu interpretaciju politike zaštite; dele se na
specifikacione standarde i proceduralne standarde.
Normativni okvir: (Zakoni i podzakonska akta u oblasti zaštite) ĉine sa
standardima zaštite metodološku osnovu na kojoj se izraĊuju
dokumenata programa zaštite; zakoni i podzakonska akta u oblasti zaštite
obezbeĊuju osnovni okvir za šire uspostavljanje i implementaciju
programa zaštite IKT sistema u organizacijama, kao i mehanizme
sankcionisanja koji predstavljaju i faktore motivacije da se ovi zakoni
sprovode.
Proceduralni interni standardi: korisni mehanizmi za opisivanje
procedura za administraciju zaštite ili korisniĉke aktivnosti; ukljuĉuju
samo najvaţnije korake, bez tehniĉkih detalja i nisu specifiĉne za IS
(platformu) nego su generiĉke.
Specifikacioni interni standardi: definišu sistem osnovne zaštite
(optimalan, idealan) za datu konfiguraciju IKT sistema. Svaka
organizacija definiše ovaj standard na bazi teoretskih razmatranja i
izborom osnovnih kontrola zaštite iz kataloga kontrola za najbolju praksu
zaštite, specifiĉnih za sistem i okruţenje, a na bazi rezultata analize
rizika.
Standardi zaštite: obezbeĊuju pravila upravljanja sistemom zaštite, a
mogu se izvoditi iz normativa (zakona) i regulatornih propisa, ili
industrijske prakse i iskustava.

- 93 -
6. LITERATURA

1. Aizuddin A., The common criteria ISO/IEC 15408– the insight,

some thoughts, questions and issues,
http://www.niap.nist.gov/cc-scheme, 2002.
2. American Bar Association, Section of Science &Technology
Law, Privacy & Computer Crime Committee, International
Strategy for Cyberspace Security,
www.abanet.org/abapubs/books/cybercrime/, 2003.
3. American National Standards Institute-ANSI: Electronic
Standards Store,
http://webstore.ansi.org/ansidocstore/default.asp, avgust 2003.
4. CCIMB-99-031, Common Criteria for Information Technology
Security Evaluation, Part 1: Introduction and general model,
Version 2.1, http://www.commoncriteria.org, 1999.
5. Grance T., Kent K., Kim B., Computer Security Incident
Handling Guide, NIST SP 800-61,
http://www.nist.gov/publications, January 2004.
6. http://www.cert.org/incident_notes/index.html.
7. ISF, The Standard for Good Practice for Information Security,
http://www.isf.org, V.3.0., 2003.
8. ISO/IEC 15408, Common Criteria for IT Evaluation User
Guide, http://csrc.nist.gov/cc/info/infolist.htm. 7
9. ISO/IEC 15443, Information Technology-Security Techniques,
http://www.iso.15443.org, 2000.
10. ISO/IEC 15504 (CMM), http://www.iso.15504.org, 2000.
11. ISO/IEC 17799:2000, Information Technology – Code of
practice for information security management,
http://www.iso.17799.org, 2003.
12. ISO/IEC 21827 (SSE CMM), System Security Engineering
Capability Maturity Model, http://www.iso.21827.org., 2000.
13. ITU-T Recommendation X.509, Information Technology –
Open system Interconnection – The directory: Public key and
attribute certificate frameworks.
14. ITU-T Recommendation X.25, Interface between data terminal
equipment and data circuit-terminating equipment for terminals
operating in the packet mode and connected to public data
networks by dedicated circuit.
15. ITU-T Recommendation X.400, Message handling services:
Message handling system and service overview

- 94 -
16. ITU-T Recommendation X.500, Information Technology –
Open system Interconnection – The directory: overview of
concepts, models and services.
17. Malkin G., The Tao of IETF: A Guide for new attenees if the
internet engineering task force,
http://www.faqs.org/rfc/rfc1539.html, avgust 2003.
18. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII, decembar,
2005.
19. NIST, Federal information processing standards publications
(FIPS PUBS), http://www.itl.nist.gov/l/fipspubs, avgust 2003.
20. NIST, Standards, NIST SP 800 53 a,b,c,
http://www.nist.gov/publications/public_affairs/standards.htm,
avgust 2003.
21. NIST, Trusted Security Evaluation Criteria,
http://www.radium.ncsc.mil/tpep, 1999.
22. Purser S., A practical guide to managing information security,
Artech House, Boston, London, www.artechhouse.com, 2005.
23. Republika Srbija, Predlog kriviĉnog zakona, Glava 27.
„Krivična dela protiv bezbednosti računarskih podataka―, ĉlan
298-304, 2004.
24. Republika Srbija, Zakon o borbi protiv visoko tehnološkog
(kompjuterskog) kriminala, usvojen u juli 2005.
25. Republika Srbija, Zakon o elektronskom potpisu, RZII, 2004.

- 95 -
6. DOKUMENTOVANJE PROGRAMA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja razumećete:

- značaj dokumentacije zaštite u sistemu zaštite

- opštu klasifikaciju dokumenata zaštite
- koncept kontrolnog okvira zaštite

Da bi se program zaštite uspostavio i razvio mora poĉivati na

odreĊenoj metodološkoj osnovi, koju ĉine interna i eksterna
dokumentacija zaštite.

Interna dokumentacija u odnosi na sistem zaštite obuhvata: Upravljačka

dokumentacija, Interne procedure, Projektnu dokumentaciju, Tehničku
dokumentaciju i Ostala dokumenta (materijal za obuku, dokumenta sa
konferencija, struĉne instrukcije).

Eksterna dokumentacija, koju u odnosu na sistem zaštite nameće

administrativni nivo organizacije obuhvata: politiku zaštite na nivou
organizacije- ISP (ili program zaštite), ostale politike zaštite, industrijski
standardi, uputstva za zaštitu i druga radna dokumenta ( radne kontrolne
liste, uzorci, katalozi kontrola zaštite, uzorci politika zaštite i dr.).

Kljuĉnu dokumentaciju zaštite ĉine: Program zaštite, Plan zaštite,

Politika zaštite, Procedure zaštite i Uputstva zaštite. Dokumenta zaštite
normalno ne komentarišu nivo servisa koje treba obezbediti odreĊenom
korisniku. Nivo servisa zaštite kojeg treba pruţiti nekom korisniku
formalizuju se potpisivanjem ugovora za nivo servisa zaštite- SLA
(Service Level Agreement), koji pruţa poverljivi (TTPS) provajder
zaštite.

U oblasti dokumentacije procesa zaštite, treba dokumentovati

formalizovane procedure odrţavati ih aţurnim i njih koristiti kao
pomoćnu dokumentaciju, što podrazumeva da svaki put ne treba raditi
novu dokumentaciju za dati proces.

- 96 -
1. KLASIFIKACIJA DOKUMENATA ZAŠTITE
Osnovne karakteristike dobre dokumentacije zaštite odreĊuju
sledeći kriterijumi: laka za upotrebu/ održavanje, sadrži tačne i ažurne
informacije, odgovarajuća za ciljne korisnike i da sadrži samo relevantne
i bitne informacije.
Na slici Sl.1.1. prikazana je klasifikacija dokumenata zaštite, [7].
Interna dokumentacija zaštite obuhvata:
1. Upravljačku dokumentaciju – ugovori, planovi, izveštaji,
budţetska dokumenta, finansijski planovi i ugovor o neotkrivanju
- NDA (Non Disclouse Agreement-),
2. Interne procedure – izveštavanja, lokalne administracije, za
kontrolu izmene dokumentacije, administratora zaštite i.t.d.
3. Projektna dokumentacija – n.p.r., implementacija skenera sistema
zaštite,
4. Tehnička dokumentacija – za ureĊaje zaštite, tehniĉki izveštaji,
testovi i sl. i
5. Ostala dokumenta - materijal za obuku, dokumenta sa
konferencija, instrukcije.

Dokumentacija zaštite

Eksterna
Interna dokumentacija
dokumentacija

Upravljačka
Politikke
dokumentacija

Interne procedure Standardi

Projektna
Uputstva
dokumentacija

Tehnička
Radna dokumenta
dokumentacija

Ostalaa dokumenta

Sl. 1.1. Klasifikacija dokumenata zaštite

- 97 -
Eksterna dokumentacija zaštite obuhvata:

1. Program zaštite ili ISP – politika zaštite na najvišem nivou

organizacije;
2. Ostale politike zaštite – na nivou IKT sistema, na nivou sistema
zaštite i politike funkcionalnih komponenti zaštite;
3. Industrijski standardi - standardi upravljanja zaštitom, standardi
za obuku, nadzor i kontrolu, evaluaciju sistema i proizvoda zaštite
i dr.;
4. Uputstva za zaštitu – uputstva za upravljanje sistemom zaštite,
pojedinaĉnim komponentama zaštite (obuku, nadzor i kontrolu,
sertifikaciju i akreditaciju, upravljanje vanrednim dogaĊajima i
kompjuterskim incidentom i dr.) i
5. Radna dokumenta – radne kontrolne liste, uzorci, katalozi
kontrola zaštite, uzorci politika zaštite i dr.

Kljuĉnu dokumentaciju zaštite koja preporuĉuje standard zaštite

ISO/IEC 17799 ĉine: Program zaštite, Plan zaštite, Politika zaštite,
Procedure zaštite i Uputstva zaštite. Dokumenta zaštite normalno ne
obuhvataju nivo servisa zaštite koje treba obezbediti odreĊenom
korisniku. OdreĊeni nivo servisa zaštite kojeg treba pruţiti nekom
korisniku formalizuje se potpisivanjem posebnih ugovora za nivo servisa
zaštite-SLA (Service Level Agreement), koji pruţa poverljivi (TTPS)
provajder zaštite, [1].

- 98 -
2. USPOSTAVLJANJE KONTROLNOG OKVIRA

2.1. Kontrolni okvir

Kontrolni okvir ĉine saopštenja politika zaštite, standardi zaštite,

procedure, radna dokumenta i kontrole tehniĉkih rešenja implementiranih
da obezbede dnevno operativni rad sistema. Kontrolni okvir, kao rezultat
strategijskih inicijativa sporo je promenljiva komponenta programa
zaštite, a mera u kojoj odgovora dnevnim potrebama organizacije dobar
je pokazatelj zrelosti organizacije. Upravljanje rizikom je dinamiĉki
promenljiva komponenta programa i procesa zaštite. Kako procesi
organizacije postaju zreliji oĉekuje se postepena zamena kontrolnog
okvira upravljanog politikom zaštite, sa procesom procene rizika, što
ukazuje na sposobnost organizacije da brţe reaguje na promene u
okruţenju (Sl. 2.1). Na slici Sl. 2.1. prikazani su odnosi politike zaštite,
analize rizika i okvira za upravljanje zaštitom, koji evoluiraju u vremenu
sazrevanja procesa zaštite od politike do implementacije rezultata analize
rizika, [7].
Pomeranje od okvira upravljanog politikom

Politika
prema okviru upravljanim rizikom

Def
iniš
e

Upravljački okvir:
- Standardi
- Uputstva
- Tehničke kontrole

nira
Rafi
Procena
rizika
De
finiš
e
Upravljački okvir:
- Taktička rešenja

Sl. 1.2. Sazrevanje procesa zaštite i pomeranje okvira zaštite sa

upravljanja politikom zaštite na upravljanje procenom rizika

Za većinu organizacija kontrolni okvir u velikoj meri zavisi od spoljnih

partnera (poverljivih provajdera servisa zaštite - TTPS). Veći je problem
za organizacije koje same implementiraju i koriste tehnologije zaštite. Na
primer, u antivirusnoj zaštiti, koja je efikasna u dubinskoj arhitekturi
sistema slojevite zaštite, ako skeniranje sistema na viruse nije obavljeno
na vreme, moţe se propustiti indikacija stvarnog problema. Pored toga,
ne sprovoĊenje procedura zaštite moţe ukazivati da se incident dogodio
upravo u tom trenutku. MeĊutim, ovakav strogi reţim nadzora i kontrole
sistema zaštite zahteva veliku disciplinu, pa obavezne i rigidne politike

- 99 -
zaštite mogu preţiveti uglavnom u vojnoj i policijskoj sredini, ili u
drţavnoj upravi, ali teţe u poslovnom okruţenju. Generalno, politike
zaštite u programu zaštite obezbeĊuju: vodeće instrukcije za upravljanje
programom zaštite, formiraju bazu za upravljački okvir kontrola zaštite,
definišu uloge i odgovornosti u implementaciji programa zaštite i
dokumentuju stav organizacije u odnosu na sva obuhvaćena pitanja
zaštite.

2.2. Uputstva za zaštitu

Uputstvo za zaštitu je celovit dokument o zaštiti (Priručnik za

zaštitu) namenjen administratorima i glavnim menadţerima zaštite kao
pomoć u projektovanju sistema zaštite i upravljanju programom zaštite
od inicijalnog koncepta do implementacije i odrţavanja sistema zaštite,
obuke i procesa neprekidnog nadzora i kontrole. Uputstvo za zaštitu treba
da: bude sveobuhvatno i dovoljno detaljno; obuhvata sve komponente
zaštite, sadrţi uzorke plana, politika i procedura zaštite, raznih upitnika,
tabela i dijagrama, koji pomaţu specijalistima zaštite u procesu
definisanja programa zaštite, izrade plana i politika zaštite, projektovanja
i kontrole sistema zaštite. Uputstvo, takoĊe, treba da sadrţi instrukcije za
korišćenje kataloga upravljaĉkih, operativnih i tehniĉkih kontrola
najbolje prakse zaštite za osnovni i povećani nivo zaštite kritiĉnih
objekata IKT sistema od uticaja pretnji na niskom, srednjem i visokom
nivou rizika.

Uputstva za zaštitu, namenjena korisnicima IKT sistema orijentisana su

na odreĊene grupe korisnika i obraĊuju odreĊene komponente zaštite u
delokrugu odgovornosti te grupe, [5].

- 100 -
2.3. Pregled i aţuriranje dokumenata zaštite

Bezbednost i zaštita nisu statiĉki elementi. Novi hardversko/

softverske metodi napada i iskorišćenja ranjivosti objekata IKT sistema
neprekidno se razvijaju i usavršavaju. Od kritiĉnog znaĉaja je da se
regularni pregled i revizija dokumenata programa, plana, politike i
procedura zaštite vrši najmanje jedanput godišnje. Za operativnu zonu
koja zahteva veći stepen bezbednosti i zaštite ta kontrola mora biti ĉešća.
Interna i eksterna (auditing) kontrola zaštite, takoĊe su sredstva za
reviziju dokumenata programa zaštite i korekciju otkrivenih ranjivosti.
Revizija programa zaštite zahteva se i sa legalnog aspekta: da se izvrši
usaglašavanje sa novim normativima u oblasti zaštite. TakoĊe,
tehnološke promene u IKT i sistemima zaštite, zahtevaju znaĉajne
promene u planu zaštite, posebno na funkcionalnom nivou i nivou IKT
sistema, osnovnoj politici i procedurama zaštite. Promene u poslovima
organizacije, upravi ili kulturi rada, mogu zahtevati izmene politike i
procedura zaštite na nivou organizacije.

Bitno je da se dokumenta programa zaštite podvrgavaju regularnoj

reviziji u pogledu efikasnosti, usaglašenosti i ranjivosti. Kroz generalno
prihvatanje sveobuhvatnog programa zaštite, privrţenost najboljoj praksi
zaštite, inkorporaciju GAISP principa zaštite, standarda, uputstava i
drugih dokumenata zaštite, kao i ukljuĉivanje svih zaposlenih, nazire se
globalna strategija za razvoj i implementaciju programa zaštite.

- 101 -
3. REZIME

Dobra dokumentacija zaštite mora biti laka za upotrebu i

odrţavanje, taĉna i aţurna, adekvatna za ciljne korisnike i relevantna.
Moţe se klasifikovati, u odnosu na sistem zaštite, na interna i eksterna.

Interna dokumentacija obuhvata: upravljačku dokumentaciju – ugovori,

planovi, izveštaji, finansijski planovi i dr.; interne procedure - interni
izveštaji i procedure lokalne administracije i dr.; projektnu
dokumentaciju - projektna i interna dokumentacija (npr., implementacije
skenera zaštite); tehničku dokumentaciju - za ureĊaje zaštite, tehniĉki
izveštaji i sl, i ostala dokumenta - zakonska, materijal za obuku, struĉne
instrukcije i sl. Eksterna dokumentacija obuhvata: programsku politiku
zaštite; ostale politike zaštite; standarde; uputstva za zaštitu i radna
dokumenta. Uputstvo za zaštitu je celovit dokument o zaštiti namenjen
administratorima i glavnim menadţerima zaštite kao pomoć u
projektovanju sistema zaštite i upravljanju programom i sistemom zaštite
od inicijalnog koncepta do implementacije i odrţavanja sistema zaštite i
neprekidnog nadzora i kontrole.

Bezbednost i zaštita nisu statiĉki elementi. Novi hardversko/softverske

metodi napada i iskorišćenja ranjivosti objekata IKT sistema neprekidno
se razvijaju i usavršavaju. Od kritiĉnog znaĉaja je da se regularni pregled
i revizija dokumenata programa, plana, politike i procedura zaštite vrši
najmanje jedanput godišnje.

Kontrolni okvir ĉine saopštenja politika zaštite, standardi, procedure,

radna dokumenta i tehniĉke kontrole zaštite, implementirani da obezbede
dnevno operativni rad sistema. Kontrolni okvir je sporo promenljiva
komponenta programa zaštite, a upravljanje rizikom -dinamiĉki
promenljiva. Kako procesi organizacije postaju zreliji oĉekuje se
postepena zamena kontrolnog okvira upravljanog politikom zaštite, sa
procesom procene rizika, što ukazuje na sposobnost organizacije da brţe
reaguje na promene u okruţenju.

- 102 -
4. KLJUĈNI TERMINI

Interna dokumentacija: Upravljaĉka dokumentacija, Interne procedure,

Projektnu dokumentaciju, Tehniĉku dokumentaciju i Druga dokumenta
(materijal za obuku, dokumenta sa konferencija, struĉne instrukcije).
Eksterna dokumentacija: Politika zaštite na nivou organizacije-ISP (ili
program zaštite), druge politike zaštite, industrijski standardi, uputstva
za zaštitu i druga radna dokumenta (radne kontrolne liste, uzorci,
katalozi kontrola zaštite, uzorci politika zaštite i dr.).
Upravljaĉku dokumentacija: ugovori, planovi, izveštaji, budţetska
dokumenta, finansijski planovi i NDA (Non Disclouse Agreement-
ugovor o neotkrivanju).
Interne procedure: interni izveštaji i procedure lokalne administracije,
procedure za kontrolu izmene dokumentacije, za administratora zaštite
i.t.d.
Projektna dokumentacija: dokumenta koja se formiraju u toku procesa
razvoja i implementacije projekta i druga interna dokumentacija koja se
odnosi na projekat zaštite. Tehniĉka dokumentacija: tehniĉka
dokumentacija za ureĊaje zaštite, tehniĉki izveštaji, testovi i sl.
Ostala dokumenta zaštite: zakonska dokumenta, materijal za obuku,
dokumenta sa konferencija, struĉne instrukcije.
Program zaštite: ili ISP – politika zaštite na najvišem nivou
organizacije.
Ostale politike zaštite: politike zaštite na nivou IKT sistema, na nivou
sistema zaštite i funkcionalne politike zaštite;
Industrijski standardi: standardi upravljanja zaštitom, standardi za
obuku, nadzor i kontrolu, evaluaciju sistema i proizvoda zaštite i dr.;
Uputstva za zaštitu: uputstva za upravljanje sistemom zaštite,
pojedinaĉnim komponentama zaštite (obuku, nadzor i kontrolu,
sertifikaciju i akreditaciju, upravljanje vanrednim dogaĊajima i
kompjuterskim incidentom i dr.) i
Radna dokumenta: radne kontrolne liste, uzorci, katalozi kontrola
zaštite, uzorci politika i procedura zaštite i dr.
Kontrolni okvir: skup saopštenja politika zaštite, standarda zaštite,
procedura, radnih dokumenta i tehniĉkih kontrola rešenja zaštite
implementiranih da obezbede dnevno operativni rad sistema zaštite;
sporo promenljiva komponenta programa zaštite.

- 103 -
5. LITERATURA

1. Brown, S. Castell, G. Gray, P. Muller, "User Requirements for

Trusted Third Party Services", INFOSEC Project Report
S2101/01, Commission of the European Communities, DG XIII,
B-6, Oct 1993.
2. Harold F. Tipton, Micki Krause: The information security
handbook, http://csrc.nist.gov/policies/ombencryption-
guidance.pdf , 2003.
3. NIST SP 800-12, An introduction to computer Security- The NIST
Handbook, , http://csrc.nist.gov/publications/nistpubs/800-
12/sp800-12.pdf, avgust 2003.
4. NIST SP 800-14, Generally Accepted Principles and Practices
for Security, http://csrc.nist.gov/publications/nistpubs/800-
14/sp800-14.pdf, 2002.
5. NIST SP 800-18, Guide for developing Security Plans for IT
Systems, http://csrc.nist.gov/publications/nistpubs/800-18/sp800-
18.pdf, 2003.
6. OECD – Guidelines for the Security of information systems and
Networks, 2000.
7. Purser S., A practical Guide to Managing Information Security,
Artech House, Boston-London, www.artechhouse.com, 2004.
8. RFC 2196, Site Security handbook,
http://www.faqs.org/rfc/rfc2196.html, 2003.
9. The Canadian Handbook on Information Technology (IT)
Security, www.canada.gov.itsec.com, 1999.

- 104 -
7. OPŠTI MODEL SERVISA ZAŠTITE

0. UVOD

Kada proučite ovo poglavlja razumećete:

- značenje termina servisi zaštite

- prirodu različitih podela servisa zaštite
- koncept opšteg, sveobuhvatnog modela servisa zaštite
- servise zaštite u distribuiranom IKT sistemu
- proces implementacije servisa zaštite
- servise poverljivog provajdera zaštite (TTPS)

U skladu sa programom, politikama i procedurama zaštite, a sa

ciljem suzbijanja rizika od dinamiĉki promenljivih, kombinovanih
faktora pretnji na prihvatljivi nivo, implementirani skup upravljaĉkih,
operativnih i tehniĉkih kontrola zaštite izvršava bezbednosne funkcije, ili
servisi zaštite. Neki servisi obezbeĊuju primarnu zaštitu od pretnji, dok
drugi servisi otkrivaju realizovanu pretnju-napad, (npr., servis nadzora i
kontrole) ili podrţavaju primarne servise zaštite. Servisi zaštite
specificiraju se na osnovu: zahteva i ciljeva zaštite, procene pretnji i
faktora rizika, poverljivosti sadrţaja, bezbednosne procene personala ,
procene fiziĉke bezbednosti objekata u mreţi i dr.

Podela servisa zaštite moţe se izvršiti na osnovu više kriterijuma, od

kojih je primarni kriterijum podele kontrola zaštite na upravljaĉke,
operativne i tehniĉke, na osnovu kojeg se primarni servisi zaštite dele na
upravljačke, operativne i tehničke servise. Primarni upravljaĉki servisi
zaštite realizuju upravljaĉke kontrole preko mehanizama prinude i
nametanja normativa, politike, standarda zaštite i drugih dokumenata
zaštite - Izveštaja o analizi rizika, Izjava o osetljivosti IKT sistema i sl.
Primarni operativni servisi zaštite realizuju operativne kontrole preko
uputstava i pravilnika kao što su Uputstvo za fizičko-tehničku zaštitu,
Uputstvo za upravljanje vanrednim dogaĎajem, Uputstvo za upravljanje
kompjuterskim incidentom i dr. Primarni tehniĉki servisi zaštite realizuju
tehniĉke kontrole implementacijom hardversko-softverskih mehanizama i
protokola zaštite.

Ova podela nije potpuno jednoznaĉna pošto su servisi zaštite

meĊuzavisni, kombinuju se i meĊusobno dopunjuju u izvršavanju
postavljenih bezbednosnih ciljeva i funkcija zaštite. Bolje rezultate daje

- 105 -
opšti model koji prikazuje primarne servise sa elementima za podršku
implementacije ukupnih kapaciteta zaštite i njihovima meĊusobnim
odnosima. Opšti model je orijentisan više na tehniĉke servise zaštite,
klasifikovane na osnovu kriterijuma primarne funkcionalne namene, ali u
kontekstu i sa meĊuzavisnostima sa sekundarnim servisima koji
podrţavaju primarne servise zaštite potpunije opisuje servise zaštite.
Opšti model deli servise zaštite na servise za: podršku, zaštitu
(sprečavanje) i oporavak. Primeri servisa zaštite su: I&A, kontrola
pristupa (AC), Zaštita poverljivosti podataka i informacija, Zaštita
integriteta podataka i informacija, Zaštita raspoloţivosti podataka i
informacija, Neporecivost aktivnosti, Nadzor i kontrola i dr.

- 106 -
1. SERVISI ZAŠTITE

1.1. Bezbednosna misija i ciljevi

Bezbednosna misija sistema zaštite je da omogući odrţavanje

bezbednosnog stanja IKT sistem organizacije na nivou preostalog rizika,
prihvatljivog za organizaciju, njene partnere i korisnike i da time
obezbedi pouzdano izvršavanje poslovnih ciljeva i misije organizacije.
Bezbednosna misija sistema zaštite postiţe se realizovanjem primarnih
bezbednosnih ciljeva, koji se definišu na osnovu bezbednosnih zahteva, a
obezbeĊuju zaštitu: raspoloživosti (Availability), integriteta (Integrity) i
poverljivosti (Cofidentiality) informacija.

Ova tri bezbednosna cilja najĉešće se navode kao dovoljan skup ciljeva
zaštite u relevantnim standardima zaštite (ISO/IEC 17799, NIST
standardi), jer pokrivaju relativno nezavisne skupove kljuĉnih atributa
informacija. U nekim standardima i specifiĉnim komponentama zaštite
(CC evaluacija, sertifikacija i akreditacija, PKI, digitalni potpis i dr.)
navode se i sledeći relevantni bezbednosni ciljevi obezbeĊivanja:
kontrolisane odgovornosti (Accountability)- pripisane i prihvaćene
odgovornosti do individualnog nivoa; neporecivosti – nemogućnost
poricanja izvršenih aktivnosti; autentifikacije -verifikacije identiteta
korisnika i bezbednosne garancije (Assurance) - poverenja ili sigurnosti
da sistema zaštite obezbeĊuje zahtevani nivo bezbednosti IKT sistema,
servisa, aplikacija, podataka i informacija.

U kontekstu sistema zaštite, bezbednosni cilj zaštite su meĊuzavisni:

zaštita integriteta obuhvata neporecivost i autentifikaciju; zaštita
raspoloţivosti obuhvata kontrolisanu odgovornost, koja, pak, zavisi od
mehanizma za obezbeĊivanje neporecivosti; bezbednosnu garanciju
obezbeĊuju sva tri primarna bezbednosna cilja zajedno, pa je u većini
sluĉajeva skup primarnih bezbednosnih ciljeva dovoljno reprezentativna
taksonomija, za većinu bezbednosnih problema.

Zahtev za raspoloživost namenjen je da se za ovlašćene korisnike

obezbedi pouzdan rad i raspoloţivost podataka i informacija, sistema,
servisa, aplikacija, po ukazanoj potrebi. Ovaj bezbednosni cilj štiti sistem
od: namernog ili sluĉajnog pokušaja da se izvrši neovlašćeno kašnjenje
podataka, odbijanja izvršavanja servisa (DoS) ili davanja podataka i od
pokušaja da se sistem ili podaci koriste za neovlašćene svrhe.

- 107 -
ObezbeĊivanje raspoloţivosti sistema, servisa i podataka vrlo ĉesto je
najvaţniji bezbednosni cilj u mnogim organizacijama, [2].

Zahtevi za zaštitu integriteta ima dva semantiĉka znaĉenja:

– zaštita integriteta podataka i informacija, koja oznaĉava da

podaci i informacije u toku skladištenja, procesiranja ili prenosa
nisu menjani na neovlašćen naĉin, i
– zaštita integriteta sadržaja i sistema, koja oznaĉava kvalitet
sistema da u njemu nema neovlašćenih manipulacija nad
sadrţajima i kada sistem na predviĊen naĉin izvršava namenjene
funkcije.

Zahtev za zaštita poverljivosti i privatnosti ima za cilj da se privatne ili

poverljive informacije ne otkrivaju neovlašćenim licima. Zaštita
poverljivosti i privatnosti primenjuje se na uskladištene podatke, podatke
u toku procesiranja i u toku prenosa. U pogledu znaĉaja, mnoge
organizacije ĉesto stavljaju ovaj cilj iza zahteva za integritet ili
raspoloţivost. MeĊutim, u sistemima za posebne namene i za specifiĉne
tipove osetljivih informacija (npr. autentifikacione informacije) zaštita
poverljivosti i privatnost je od prioritetnog znaĉaja.

Cilj obezbeĊivanja kontrolisane odgovornosti, od entiteta do svakog

pojedinca u IKT sistemu, je da se akcije svakog entiteta ili pojedinca
mogu pratiti po jednoznaĉno registrovanim tragovima. Servis za
ostvarivanje ovog cilja najĉešći je zahtev u politikama zaštite većine
organizacija i direktno obuhvata odvraćanje napadaĉa, izolaciju grešaka,
detekciju i spreĉavanje upada, oporavak sistema i neophodni normativni
okvir.

Zahtev za bezbednosnu garancija (bezbednosnu pouzdanost, sigurnost,

eng. assurance) sistema zaštite osnova je za sticanje poverenja da
upravljaĉke, operativne i tehniĉke kontrole zaštite rade pouzdano u
predviĊenom reţimu zaštite IKT sistema.

- 108 -
Ovaj cilj se ostvaruje kada su ostala 4 bezbednosna cilja (integritet,
raspoloživost, poverljivost i kontrolisana odgovornost), adekvatno
realizovani kroz specifiĉnu implementaciju i kada je obezbeĊena:

– zahtevana funkcionalnost i korektna implementacija kontrola

sistema zaštite,
– dovoljan nivo zaštite od nenamernih grešaka (korisnika ili
programa) i
– dovoljna otpornost sistema zaštite na namerni proboj ili
zaobilaţenje.

Bezbednosna pouzdanost sistema zaštite bitan je bezbednosni cilj i bez

njega smatra se da nisu realizovana ostala 4 bezbednosna cilja. MeĊutim,
postizanje ovog cilja zaštite neprekidan je proces i stalno ga treba
odrţavati na odreĊenom nivou, koji varira od sistema do sistema.

- 109 -
1.2. MeĊuzavisnost bezbednosnih ciljeva

Pet bezbednosnih ciljeva meĊusobno su zavisni i retko se moţe

ostvariti jedan bez uticaja drugih (Sl.1.1.), [4], [9], [2]. Zato svako
smanjivanje skupa bezbednosnih ciljeva zahteva odgovarajuću
aproksimaciju i razmatranje ove meĊuzavisnosti.

Poverljivost Integritet

Integritet Poverljivost

Kontrolisana
Raspoloţivost
odgovornost

Poverljivost Integritet Poverljivost Integritet

Bezbednosna pouzdanost sistema zaštite

Sl.1.1.MeĊuzavisnost bezbednosnih ciljeva

Bezbednosni cilj zaštite poverljivosti zavisi od zaštite integriteta zato što,

ako se naruši integritet sistema, nema više smisla oĉekivati da je
mehanizam zaštite poverljivosti još uvek validan. Bezbednosni cilj zaštite
integriteta zavisi od zaštite poverljivosti zato što, ako je poverljivost
odreĊenih informacija izgubljena (n.p.r. pasvord administratora), tada je
vrlo verovatno da će mehanizam zaštite integriteta biti zaobiĊen i
narušen. Raspoloživost i kontrolisana odgovornost zavise od servisa
zaštite poverljivosti i integriteta zato što, ako se za odreĊene informacije
naruši poverljivost (n.p.r. pasvorda administratora), mehanizmi koji
implementiraju ovaj servis lako se zaobilaze, bezvredni su i narušavaju se
raspoloţivost i kontrolisana odgovornost, a ako se naruši integritet
sistema, tada se narušava i validnost mehanizama koji realizuju
bezbednosni cilj poverljivosti, a time se narušavaju i raspoloţivost i
odgovornost.

Sa bezbednosnom pouzdanošću (sigurnošću) sistema zaštite u

meĊuzavisnoj vezi su svi bezbednosni ciljevi. Kada se projektuje sistem
zaštite, projektant uspostavlja graniĉnu vrednost bezbednosne
pouzdanosti, kao cilj kojem se teţi. Ovaj se cilj postiţe istovremenim
definisanjem i ispunjavanjem funkcionalnih zahteva u svakom od
preostala 4 bezbednosna cilja i kvalitetnom realizacijom i

- 110 -
implementacijom funkcionalnih zahteva, u skladu sa standardima dobre
prakse i procedurama zaštite.

Cilj obezbeĊivanja bezbednosne pouzdanosti istiĉe ĉinjenicu da se za

bezbednost nekog sistema moraju, ne samo ispuniti projektovani
funkcionalni zahtevi koji obuhvataju tehničku pouzdanost sistema
(izraţava se verovatnoćom ili srednjim vremenom rada bez otkaza), nego
i spreĉiti neţeljeni procesi i steći poverenje (sigurnost) u sistem zaštite.

- 111 -
2. OPŠTI MODEL SERVISA ZAŠTITE

Opšti model servisa zaštite (Sl.2.1) obuhvata primarne servise,

sekundarne elemente koji podrţavaju implementaciju kapaciteta IKT
zaštite i njihove meĊusobne veze. U odnosu na primarnu namenu, model
klasifikuje servise na, [9]:

 Servise za podršku, generiĉke, koji obuhvataju najveći deo kapaciteta

IKT zaštite;
 Servise za zaštitu (sprečavanje), namenjene za spreĉavanje proboja
ili zaobilaţenja implementiranih mehanizama zaštite i
 Servise za oporavak, namenjene na detekciju upada i oporavak
sistema posle proboja.

Bezbednosni ciljevi ostvaruju se realizacijom servisa zaštite - izvršnih

funkcija sistema zaštite, pa je opšta meĊuzavisnost servisa zaštite
identiĉna meĊuzavisnosti bezbednosnih ciljeva. Tehniĉki servisi zaštite
realizuju se implementacijom hardversko - softverskih mehanizama
(alata) zaštite, preko kojih se ostvaruju tehniĉke kontrole sistema zaštite.

Poverljivostt
transakcija

Autentifikacija Neporecivost

Korisnik
ili Autorizacija Nadzor i kontrola
proces

Kontrola
Resurs IS
pristupa
Dokaz o
celovitosti
Detekcija
upada Legenda:
Restauracija
Servisi za
bezbednog stanja
sprečavanje

Zaštićene komunikacije Servisi za

(od otkrivanja, zamene, modifikacije, …) oporavak
Identifikacija (i imenovanja)
Servisi za
Upravljanje kriptološkim ključevima
podršku
Administracija sistema zaštite
Sistemska zaštita (najmanje privilegija, ponovno
korišćenje, separacija procesa i.t.d.)

Sl. 2.1. Opšti model tehniĉkih servisa zaštite

- 112 -
2.1. Servisi za podršku

Servisi za podršku, po svojoj prirodi u korelaciji su sa drugim

servisima, a obuhvataju:

– Identifikaciju: obezbeĊuje jednoznaĉnu identifikaciju subjekata

(korisnika, procesa) i objekata IKT sistema.
– Upravljanje kriptografskim ključem: mora biti pouzdano i
bezbedno kada se kriptografske funkcije implementiraju u druge
servise; obuhvata generisanje, zamenu i uništavanje kljuĉeva.
– Administraciju zaštite: ObezbeĊuje operativno upravljanje
bezbednosnim karakteristikama sistema, zadovoljava potrebe
specifiĉne instalacije i promene operativnog okruţenja.
– Sistemsku zaštitu:. Kvalitet implementacije osnova je poverenja
u tehniĉke servise zaštite. Primeri sistemske zaštite su: zaštita od
ponovnog korišćenja objekata, davanje najmanje privilegija,
separacija procesa, modularna arhitektura, slojevitost zaštite i
minimizacija poverljivih objekata u sistemu.

2.2. Servisi za zaštitu (spreĉavanje)

Servisi za zaštitu (za spreĉavanje ili preventivni servisi) spreĉavaju

da doĊe do proboja sistema zaštite, a generiĉki obuhvataju servise za.

– Zaštitu komunikacija: obezbeĊuju integritet, raspoloţivost i

poverljivost informacija u toku prenosa. Sva tri elementa obiĉno
su bezbednosni zahtevi, s tim da je zaštita poverljivosti uvek
neophodna za autentifikacione informacije.
– Autentifikaciju: verifikacija validnosti identiteta subjekta
(korisnika, procesa) u IKT sistemu za koje se subjekti
predstavljaju.
– Autorizaciju: davanja ovlašćenja omogućava specifikaciju
dopuštenih aktivnosti (po principu: sve što je dopušteno nije
zabranjeno i sve što nije zabranjeno - dopušteno je) subjekata nad
objektima IKT sistem, a zatim upravljanje odobrenim akcijama u
datom sistemu.
– Kontrolu pristupa sa prinudom: kada se verifikuje zahtev
subjekta za pristup odreĊenim procesima u IKT sistemu,
neophodna je prinuda za implementaciju definisane politike
zaštite. Servis kontrole pristupa obezbeĊuje mehanizam prinude,

- 113 -
 koji ĉesto moţe biti distribuiran u sistemu, pošto dobijenu
dozvolu za pristup odgovarajućem bezbednosnom nivou u IKT
sistem, ne odreĊuje samo preciznost odluke za pristup, nego i
jaĉina prinude te odluke.
– Neporecivost: zavisi od mehanizma koji obezbeĊuje da pošiljalac
ne moţe poreći izvršenu aktivnost, a primalac ne moţe poreći
rezultat te aktivnosti. Ovaj servis smanjuje potrebu za prevenciju i
detekciju, a smešten je u kategoriju preventivnih servisa zato što
implementirani mehanizmi apriori spreĉavaju mogućnost
poricanja aktivnosti. Servis se tipiĉno izvršava na predajnoj ili
prijemnoj strani.
– Poverljivost i privatnost transakcija: obezbeĊuje zaštitu
poverljivosti informacija i privatnosti korisnika IKT sistema.
Servis štiti od gubitka tajnosti, poverljivosti i privatnosti u toku
transakcije koju korisnik izvršava.

Neki standardi (NIST, ISO/IEC 17799) navode minimalan i dovoljan sup

od tri primarna cilja zaštite (što je u skladu i sa objektno orijentisanim
pristupom), odnosno, servisa za:
– zaštitu poverljivosti,
– zaštitu integriteta koja ukljuĉuje (ali nije ograniĉena samo na)
autentifikaciju, neporecivost i kontrolisanu odgovornost i
– zaštitu raspoloživosti informacija i sistema.

- 114 -
2.3. Servisi za detekciju i oporavak

Pošto ni jedna preventivna mera nije savršena i praktično nema

sistema zaštite koji obezbeĎuje apsolutnu zaštitu, u svakom sistemu
zaštite neophodno je obezbediti servise za detekciju povreda sistema
zaštite i preduzimanje akcija za redukciju njihovog uticaja, kao i servise
za oporavak sistema. U servise za detekciju i oporavak spadaju:

– Detekcija upada i merenje nivoa zaštite: obezbeĊuje detekciju

povrede sistema zaštite i efikasan odgovor u pravo vreme i na
pravi naĉin.
– Restauracija bezbednog stanja: obezbeĊuje oporavak sistema u
prvobitno bezbedno stanje, posle proboja sistema zaštite;
obuhvata mehanizme za snimanje rezervnih kopija (bekapovanje)
podataka, sistemskih programa i aplikacija.
– Nadzor i kontrola: bezbednosno relevantnih dogaĊaja kljuĉne su
aktivnosti posle detekcije i oporavaka sistema zaštite od proboja i
izmeĊu dva proboja; predstavlja neprekidnu aktivnost zaštite.

Na slikama 2.2.-2.6. prikazani su funkcionalni modeli primarnih servisa

za postizanje bezbednosnih ciljeva: raspoloživosti (Sl. 2.2), integriteta
(Sl.2.3), poverljivosti (Sl. 2.4), kontrolisane odgovornosti (Sl. 2.5) i
bezbednosne pouzdanosti (Sl. 2.6).

U savremenim poslovnim IS servis zaštite raspoloţivosti informacija

ĉesto je znaĉajniji od ostala dva primarna servisa zaštite poverljivosti i
integriteta informacija. U cilju razumevanja znaĉaja i teţine problema
obezbeĊivanja servisa za zaštitu raspoloţivosti informacija, u Vežbi GI
P7A razvijen je primer proraĉuna tehniĉke i funkcionalne pouzdanosti,
koja bitno utiĉe na ukupnu bezbednosnu pouzdanost i raspoloţivost
informacija i IKT sistema.

- 115 -
 Poverljivost
transakcija

Autentifikacija

Korisnik
ili Autorizacija
proces

Kontrola
Resurs IS
pristupa
Dokaz o
celovitosti
Detekcija
upada
Restauracija Legenda:
bezbednog stanja Sprečavanje

Oporavak
Zaštićene komunikacije
(od otkrivanja, zamene, modifikacije, …)
Podrška

Sl. 2.2. Primarni servisi raspoloţivosti

Korisnik
ili Autorizacija
proces

Kontrola
Resurs IS
pristupa
Dokaz o
celovitosti
Detekcija
upada
Restauracija Legenda:
bezbednog stanja Sprečavanje

Zaštićene komunikacije Oporavak

(od otkrivanja, zamene, modifikacije, …)
Podrška

Identifikacija (i imenovanja)

Upravljanje kriptološkim ključevima

Sl. 2.3. Primarni servisi za zaštitu integriteta

- 116 -
 Poverljivost
transakcija

Korisnik Autorizacija
ili
proces

Kontrola
Resurs IS
pristupa

Zaštićene komunikacije
(od otkrivanja, zamene, modifikacije, …) Legenda:
Sprečavanje
Identifikacija (i imenovanja)
Oporavak

Upravljanje kriptološkim ključevima

Podrška

Sl. 2.4. Primarni servisi za zaštitu poverljivosti

Autentifikacija Neporecivost

Korisnik
ili Autorizacija Nadzor i kontrola
proces

Kontrola
Resurs IS
pristupa
Dokaz o
celovitosti
Detekcija
upada
Legenda:
Sprečavanje

Identifikacija (i imenovanja) Oporavak

Podrška
Upravljanje kriptološkim ključevima

Sl. 2.5. Primarni servisi za obezbeĊenje kontrolisane odgovornosti

(accountability)

- 117 -
 Autentifikacija

Korisnik
ili Kontrola
proces Resurs IS
pristupa
Dokaz o
celovitosti

Detekcija Restauracija
upada bezbednog stanja

Legenda:
Sprečavanje

Zaštićene komumikacije Oporavak

(od otkrivanja, zamene, modifikacije,…)
Administracija sistem zaštite Podrška

Sistemska zaštita (najmanje privilegija, ponovno

korišćenje, separacija procesa i.t.d.)

Sl. 2.6. Primarni servisi za obezbeĊenje bezbednosne pouzdanosti

- 118 -
2.4. Implementacija servisa zaštite u distribuiranom IKT sistemu

Servisi zaštite u distribuiranom IKT sistemu mogu biti

distribuirani fiziĉki i logiĉki, u domenima zaštite ili u okviru fiziĉkih
raĉunarskih mreţa.

Fiziĉka i logiĉka distribucija servisa zaštite i njihovi odnosi sa drugim

servisima sistema prikazani su na slici Sl.2.7, [4]. Na slici je prikazano da
svi servisi konaĉno zavise od servisa zaštite operativnog sistema hosta -
SZOS (NOSSS-Native Operation System Security Subsystem), a
bezbednosna pouzdanost sistema zaštite (assurance) je kljuĉni elemenat
koji ukljuĉuje sve kapacitete zaštite. Upravljanje sistemom zaštite je
sledeći vaţan aspekat efektivnosti i efikasnosti servisa zaštite.

Bezbednosna pouzdanost sistema

Upravljanje sistemom

Sevisi zaštite korisničkih i klijent-servera

aplikacija

Servisi zaštite na srednjem nivou

DSZ SZ
VN Servisi zaštite na niţim
OS
nivoima
DSZ SZ
VN OS
DSZVN SZ
OS
Servisi zaštite OS (SZOS)

Bezbednosna pouzdanost sistema

DSZVN- distribuirani servisi zaštite na više nivoa

SZOS -servisi zaštite operativnog sistema

Sl. 2.7. Distribuirani servisi zaštite

Distribuirani servisi zaštite baziĉno zavise od pouzdanosti sistema i

bezbednosnih servisa operativnog sistema (SZOS), [10].

- 119 -
2.4.1. Bezbednosna pouzdanost sistema

Bezbednosna garancija ili pouzdanost (eng. assurance) sistema

osnova je za poverenje korisnika da sistem i servisi zaštite ispunjavaju
ciljeve zaštite. Bezbednosna pouzdanost sistema moţe se opisati i kao
karakteristika sistema koja obezbeĊuje poverenje korisnika da sistem
ispunjava svoju namenu. Poverenje korisnika u korektnost rada
mehanizama zaštite i otpornost sistema na namerne ili sluĉajne prodore
obezbeĊuje kvalitetna implementacija adekvatnih kontrola zaštite. Već su
razvijeni tehnološki alati za merenje bezbednosne pouzdanosti IKT
sistema. Bezbednosna pouzdanost sistema moţe se povećati sa:

 primenom manje kompleksnih tehniĉkih rešenja,

 korišćenjem poverljivijih, bezbednosno i tehniĉki pouzdanijih
komponenti sistema,
 smanjenjem verovatnoće proboja (modularnim projektovanjem,
smanjenjem nivoa ranjivosti, implementacijom komponenti za
detekciju upada i oporavak sistema) i
 integracijom tehnologije adekvatne zahtevima operativnog okruţenja.

Na bezbednosnu pouzdanost sistema direktno utiĉe arhitektura IKT

sistema. Najveću pouzdanost imaju namenski sistemi, projektovani od
poverljivih komponenti tzv. poverljivi raĉunarski sistemi (Trusted
Computer Base).

2.4.2. Servisi zaštite operativnog sistema

Svaki sistem IKT zaštite u krajnjem zavisi od postojećih servisa

zaštite podsistema zaštite prirodnog operativnog sistema (NOSSS-Native
Operation System Security Subsystem), [6], koji je osnovni sloj softvera
zaštite u raĉunarskom sistemu. Ako su ovi servisi slabi, sistem IKT
zaštite moţe se zaobići ili probiti. Drugim reĉima, bezbednost IKT
sistema ne moţe biti veća od bezbednosti nosećeg OS (SZOS), što je na
Sl. 2.7. grafiĉki prikazano.

Dok neki servisi ostaju na odreĊenom logiĉkom nivou hijerarhije

apstraktnih slojeva programa raĉunarskog sistema, drugi su
implementirani kroz mehanizme distribuirane u fiziĉkom i logiĉkim
slojevima sistema, što je prikazano razmeštajem servisa zaštite na
logiĉkim nivoima: korisničkih/ klijent-server aplikacija, srednjeg sloja

- 120 -
(Midlware) i nižih slojeva (lower layers), koji su grafiĉki prikazani
direktno iznad mehanizama OS.

Model distribuiranih servisa zaštite na Sl. 2.7. pokazuje da neki

distribuirani servisi ne postoje individualno ni na jednom nivou, nego su
implementirani sa kooperativnim mehanizmima na više nivoa Tipiĉni
primeri su servisi za identifikaciju i autentifikaciju. Naime, korisniĉki
interfejs (deo programa na aplikativnom nivou, n.p.r. Telnet klijent),
mora interaktivno reagovati sa korisnikom da dobije neophodne
informacije. Ove se informacije prenose u proces koji odreĊuje da li su
primljeni podaci korektni. Ovaj proces obiĉno radi na nivou OS, ali moţe
biti na prezentacijskom, sesijskom, ili ĉak mreţnom nivou OSI modela
sistema. Nije neuobiĉajeno da se informacije skupljaju na jednoj mašini i
prenose kroz mreţu do druge mašine (na primer, mreţni autentifikacioni
server, log server i dr.). Ovaj primer pokazuje servis zaštite koji je fiziĉki
distribuiran na najmanje dve mašine u mreţi i koji zahteva kooperaciju
slojevitih mehanizama zaštite postavljenih na svih sedam nivoa OSI
mreţe.

2.4.3. Servisi zaštite u bezbednosnom domenu

Domena zaštite (bezbednosna domena, bezbednosna zona)

osnovni je koncept za mreţnu zaštitu IKT sistem i prinudnu restrikciju
toka podataka i procesa unutar i izmeĊu poverljivih (lokalnih, intranet)
mreţa u nebezbednom okruţenju (Internetu). Domena zaštite je skup
aktivnih entiteta (lica, procesa, ureĊaja), njihovih objekata podataka, i
meĊusobnih veza, koje povezuje zajedniĉka politika zaštite.

Koncept domena zaštite je osnova za formiranje bezbednih topologija

računarskih mreža (RM). Savremene RM su sve na neki naĉin povezane
sa Internetom, potencijalno opasnom mreţom. Uspostavljanje domena
zaštite izmeĊu lokalne i spoljašnjih mreţa vrši se postavljanjem jedne ili
više mreţnih barijera (Firewalls). Segment RM izmeĊu dve mreţne
barijere, naziva se periferijska mreža ili DMZ (demilitarizovana zona, ili
zaklonjena podmreţa), koja deli mreţnu infrastrukturu na tri odvojene
domene zaštite. Na Sl.2.8. prikazana je segmentacija mreţe u DMZ sa 1
(a) i 2 mreţne barijere (b), [8].

- 121 -
 (a) (b)

Sl. 2.8. DMZ sa 1 firewalls (a) i 2 fariwalls (b)

Koncept domena zaštite pomaţe da se odrede prioriteti zaštite, izvrši

klasifikacija i usmeri paţnja na probleme zaštite na bazi servisa koji se
zahtevaju u svakoj domeni. Tipiĉne domene zaštite u RM sa bezbednom
topologijom su:

1. Intranet (LAN), privatna mreţa organizacije;

2. Periferijska mreža (DMZ) koja pruţa servise korisnicima na
Internetu, a ponekad i zaposlenim u organizaciji i
3. Ekstranet, ili eksterna mreţa (tipiĉno regionalna WAN mreţa),
javne RM, Internet i generalno, nepoverljive mreţe.

Domen moţe biti logiĉki kao i fiziĉki. Podela IKT sistema organizacije u
domene, analogna je fiziĉkoj ogradi oko zgrade (npr., razliĉiti tipovi
firewalls), postavljanju kapija izmeĊu ograda (npr., gateways-mreţne
kapije) i imenovanju straţe za kontrolu saobraćaja kroz kapije (npr.,
tehniĉki i proceduralni servisi zaštite). Razliĉiti domeni zaštite unutar
organizacije meĊusobno se preklapaju.

Domeni se definišu pomoću jednog ili više sledećih kriterijuma: fizički

(npr., zgrade, kamp, region, i.t.d.), poslovni procesi (tj. personal,
finansije, i.t.d.), mehanizmi zaštite (tj. na nivou OS, na mreţnom nivou
i.t.d.).

Kljuĉni elementi koje treba razmatrati u definisanju domena su

fleksibilnost, projektovana zaštita, meĎusobni odnosi domena i slojevitost
zaštite za odreĊivanje mehanizama zaštite znaĉajnih za servise zaštite
svake domene.

- 122 -
Intranet organizacije, koja se smatra poverljivom mreţom, ako se ne
raĉuna na napade iznutra, tipiĉno je fiziĉki distribuirana i meĊusobno
povezan ureĊajima koji ĉesto nisu pod kontrolom organizacije. Interno,
organizacija moţe podeliti Intranet u departmane (relativno nezavisne
module) sa odvojenim domenima zaštite, sliĉno vodonepropusnim
vratima na pregradama broda, što pomaţe da se lakše nametne politika
zaštite organizacije i ograniĉe gubici u sluĉaju proboja sistema zaštite. Za
ovo se koriste gataways ureĊaji.

Postoji više rešenja DMZ za intranet, koje tipiĉno obezbeĊuju

polubezbednu domenu zaštite (neutralnu tampon zonu izmeĊu dve
nepoverljive mreţe) u kojoj organizacija moţe pruţiti ograničene servise
spoljnim mreţama, [8]. DMZ konfiguracija moţe se koristiti za zaštitu
web servera mreţnom barijerom, koja dopušta pristup HTTP protokolu
za web servise, ali ograniĉava sve druge protokole. Spoljašnja mreţna
barijera štiti intranet od svakog pristupa sa Interneta.

Ekstranet mreţa se obiĉno koristi za pristup partnera resursima intraneta

(deljenje informacija i servisa). Obiĉno se pravi pomoću bezbedne VPN
(Virtual Private Network) šifrovane konekcije, za koju su potrebna dva
VPN servera ili VPN server i klijent. Pojam eksternog okruženja
Intraneta organizacije nije lako odrediti. Razlika se moţe napraviti
izmeĊu transakcija koje su istinski izvan mreţe i onih koje su
ekvivalentne internim transakcijama, kao što je kriptozaštićen prenos od
taĉke-do-taĉke.

- 123 -
3. RAZVOJ I IMPLEMENTACIJA SERVISA ZAŠTITE

U skladu sa opštim principima i najboljom praksom zaštite,

servise zaštite treba obezbediti za celokupni životni ciklus sistema kroz
sledećih 6 faza, [2]:

 Faza 1: Priprema— donosi se odluku da implementacija servisa

zaštite moţe povećati efektivnost programa zaštite.
 Faza 2: Procena—odreĊuje se nivo bezbednosnog stanja tekućeg
okruţenja korišćenjem metrike zaštite i identifikuju bezbednosni zahtevi
i izvodljiva rešenja.
 Faza 3: Projektovanje—evaluiraju se potencijalna rešenja, razvija
projekat i definišu obim, ciljevi i atributi prihvatljivih rešenja servisa
zaštite iz skupa izvodljivih rešenja.
 Faza 4: Implementacija—projektant implementira izabrana rešenja
za servise zaštite.
 Faza 5: Operativni rad—obezbeĊuje se neprekidnim nadzorom
performansi servisa zaštite u odnosu na identifikovane bezbednosne
zahteve, periodiĉnom evaluacijom promena u sistemu i okruţenju,
procenom pretnji i faktora rizika i verifikacijom odrţavanja preostalog
rizika na prihvatljivom nivou sa odnosnim servisima zaštite.
 Faza 6: Odlaganje—obezbeĊuje se postupna tranzicija servisa
zaštite, kada se servis ukida (odlaţe).

- 124 -
Svi bezbednosni servisi zaštite (primarni, sekundarni i opšti) grupišu se u
jednu od sledećih primarnih kategorija: upravljačkih, operativnih i
tehničkih servisa zaštite (Tabela 3.1.). Ţivotni ciklus servisa primenjuje
se na svaki servis pojedinaĉno, bez obzira u koju kategoriju spada.
Servise zaštite mogu obezbediti same organizacije ili poverljiv

Upravljaĉki Tehnike i odgovornosti normalno obuhvaćene procesom upravljanja

servisi programom zaštite.
Servisi usmereni na kontrole zaštite koje implementiraju i izvršavaju
Operativni
ljudi (ne sistemi). Ĉesto zahtevaju tehniĉke i specijalistiĉke veštine, a
servisi
odnose se na operativne i proceduralne aktivnosti i tehniĉke kontrole.
Obuhvataju tehniĉke kontrole zaštite koje izvršavaju raĉunarski
Tehniĉki
sistemi. Ovi servisi zavise od propisnog funkcionisanja sistema i
servisi
njegove efikasnosti.

T. 3.1. Opšte kategorije servisa zaštite

- 125 -
3.1. Servisi poverljivog provajdera zaštite (TTPS)

Servise zaštite mogu obezbediti same organizacije ili poverljiva

treća strana - TTP (Trusted Third Party) zaštite u funkciji poverljivog
provajdera zaštite u IKT sistemu, definisana standardom ISO CD 10181-
1: ―TTP je autoritet bezbednosti i zaštite ili njegov agent u čije funkcije
zaštite veruju svi učesnici u IKT sistemu. Kada je TTP autoritet za zaštitu
domena, može mu se verovati za zaštitu unutar domena‖ , [4], [7].

Standard identifikuje zahteve koje treba da ispune korisnici i davaoci

(TTP) usluga i specificira i standardizuju parametre TTPS u IKT
sistemima u kojima, osim zaštite primarnih servisa (poverljivosti,
integriteta i raspoloživosti) treba štititi i meĎusobno poverenje svih
učesnika. Tipiĉni IKT sistem sa takvim zahtevima su zdravstveni IKT
sistemi i sistemi telemedicine u kojima se tradicionalno poverenje
izmeĊu pacijenata i lekara, sa elektronskim zdravstvenim kartonom i
drugim aplikacijama, nuţno prenosi u nesigurni virtuelni svet, ali i
savremeni sistemi e-Poslovnja u kojim je sve više korisnika koji se
meĊusobno ne poznaju i nemaju meĊusobno poverenje, [1, 7, 10, 11].
U analizi TTP servisa zaštite teţište je na definisanju zahteva za
uspostavljanje i menadţment TTPS, a manje na tehniĉkim zahtevima za
realizaciju funkcija TTPS, ukljuĉujući preporuke za definisanje
korisniĉkih zahteva; opis i kratak sadrţaj funkcija provajdera; elemente
uputstva za menadţment i pravila ponašanja, kao i osnovne parametre za
modelovanje TTPS. TTP servisi zaštite obavezne su komponente
višeslojne arhitekture sistema IKT zaštite. Kroz utvrĊivanje stavova
korisnika i provajdera prema ulogama i funkcijama TTPS u IKT sistemu,
generiše se konaĉan skup korisniĉkih zahteva, definišu zahtevi i priprema
realizacija funkcionalnog modela TTPS, [10]. Primena funkcionalnog
modela TTPS na primeru infrastrukture sa javnim kljuĉem (PKI) data je
u PRILOGU I 7A, [11].

- 126 -
Implementacija servisa zaštite preko TTPS moţe biti sloţena. Svaki
servis zaštite kao i aranţman za realizaciju (sopstvenu ili preko TTPS)
imaju svoju cenu i odreĊeni rizik. Za donošenja odluke treba razmotriti
sledećih 6 kategorija pitanja (Tabela 3.2).

Strategija/ Donosioci odluka moraju razmatrati implikacije uvoĊenja servisa

misija zaštite na strategiju razvoja i misiju organizacije. Propisno
implementirani i primenjeni servisi zaštite, moraju poboljšati
efikasnost radnih procesa i ne smeju ograniĉavati radne kapacitete.
Finansiranje Razmatra se u odnosu na troškove servisa zaštite u celom ţivotnom
ciklusu sistema.
Tehniĉka/ Svi IKT servisi, ĉak i upravljaĉki, imaju tehniĉke implikacije, pa
arhitekturna menadţeri IKT sistema moraju razmatrati uticaj servisa zaštite na
tehnologiju rada i arhitekturu organizacije u celom ţivotnom ciklusu
sistema.
Organizaciona Ovo pitanje se odnosi na neopipljive elemente organizacije, kao što
su gubici ugleda, konkurentnosti i potencijalnih poslova zbog
angaţovanja TTPS.
Personalna Ovo se pitanje odnosi na zaposlene u organizaciji i TTPS. Uprava
mora biti svesna uticaja odluke o implementaciji servisa zaštite na
njihove zaposlene, u odnosu na interne i eksterne servise zaštite, a sa
ciljem da ljudi ostanu najvaţniji resurs organizacije.
Politika/ Efektivna zaštita poĉinje sa jakom politikom zaštite. Implikacije
Procesi servisa zaštite na politike i procese zaštite moraju se razmatrati, da
bi se obezbedilo donošenje ispravne odluke i propisna
implementacija servisa zaštite.

T. 3.2. Pitanja za donošenje odluke za uvoĊenje servisa zaštite

- 127 -
4. REZIME

Bezbednosna misija sistema zaštite je da omogući organizaciji, da

implementacijom u IKT sistem sveobuhvatnog, integralnog, modularnog
i skalabilnog sistema zaštite na nivou rizika prihvatljivom za
organizaciju, njene partnere i korisnike, realizuje poslovnu planiranu ili
mandatnu misiju. Bezbednosna misija sistema zaštite izvršava se
realizacijom bezbednosnih ciljeva zaštite: raspoloživosti, integriteta i
poverljivosti objekata IKT sistema; kontrolisane odgovornosti
(Accountability) do individualnog nivoa i bezbednosne pouzdanosti
(garancije, eng. Assurance) sistema zaštite. Svi bezbednosni ciljevi su u
meĊuzavisnoj vezi sa bezbednosnom pouzdanošću sistema zaštite
(ukljuĉujući tehniĉku pouzdanost-verovatnoću pouzdanog rada izmeĊu
dva otkaza).

Podela servisa zaštite moţe se izvršiti na osnovu više kriterijuma, od

kojih je osnovni primarni kriterijum podele kontrola sistema zaštite na
upravljaĉke, operativne i tehniĉke, na osnovu kojeg se primarni servisi
zaštite dele na upravljačke, operativne i tehničke.

Model sveobuhvatnih servisa zaštite klasifikuje servise, na osnovu

kriterijuma primarne funkcionalne namene, na servise za: podršku,
zaštitu (sprečavanje) i oporavak. Servisi za podršku su generiĉki i
obuhvataju najveći deo kapaciteta zaštite u IKT sistemu, servisi za zaštitu
spreĉavaju proboj ili zaobilaţenje implementiranih kontrola, a servisi za
oporavak detektuju upad i oporavljaju sistem posle proboja.

Svaki sistem IKT zaštite u krajnjem zavisi od postojećih podsistema

servisa zaštite samog operativnog sistema (NOSSS). Ako su ovi servisi
slabi, sistem zaštite u IKT sistemu moţe se zaobići ili probiti. Drugim
reĉima, bezbednost IKT sistema ne moţe biti veća od bezbednosti
NOSSS.

Osnova za bezbednost i zaštitu raĉunarskih mreţa IKT sistema je koncept

domena zaštite (bezbednosnih domena) i prinudne restrikcije toka
podataka i procesa unutar i izmeĊu ovih domena. Domen je skup aktivnih
entiteta (lica, procesa, ureĊaja), njihovih objekata podataka i meĊusobnih
veza, povezanih zajedniĉkom politikom zaštite.

- 128 -
U skladu sa opštim principima i najboljom praksom zaštite, servise
zaštite treba obezbediti za celokupni ţivotni ciklus sistema zaštite kroz
faze: inicijalne pripreme, procene, projektovanja, implementacije,
operativnog rada i odlaganja, uz razmatranje niza pitanja o
implikacijama na misiju organizacije.

Servise zaštite mogu obezbediti same organizacije ili poverljivi provajder

zaštite (TTPS), definisan u standardu ISO CD 10181-1 kao ―autoritet
bezbednosti i zaštite ili njegov agent u čije funkcije zaštite veruju svi
učesnici u IKT sistemu. Kada je TTP autoritet za zaštitu domena, može
mu se verovati za zaštitu unutar domena‖.

- 129 -
5. KLJUĈNI TERMINI

Bezbednosni cilj (Security Objective): dugoroĉni cilj zaštite

poverljivosti, integriteta i raspoloţivosti.
Bezbednosni domen: skup aktivnih entiteta (lica, procesa, ureĊaja),
njihovih objekata podataka i zajedniĉke politike zaštite.
Bezbednosni zahtevi (Security Requirements): zahtevi za tipove i nivoe
zaštite, neophodni za opremu, podatke, informacije, aplikacije i objekte
da bi se ispunile zakonske obaveze, regulative uputstva i politike zaštite.
Domen zaštite: skup elemenata kojim upravlja (tj. kreira, aţurira i briše)
autoritet zaštite; definiše se na osnovu jednog ili više sledećih
kriterijuma: fiziĉki (n.p.r. zgrade, kamp, region, i.t.d.), poslovni procesi
(tj. personal, finansije, i.t.d.), mehanizmi zaštite (tj. na nivou OS, na
mreţnom nivou i.t.d.).
Mehanizmi zaštite: pojedinaĉni, individualni algoritmi, ili metodi, ili
hardversko-softverski moduli za eliminisanje bezbednosnih problema u
mreţi, koji realizaciju servise zaštite; za upravljanje mehanizmima
zaštite, odnosno, pojedinim servisima potrebno je obezbediti odreĊene
kontrolne strukture - kontrole zaštite koje ĉine sistem zaštite
kontrolabilnim i upravljivim.
Periferijska mreţa ili DMZ: segment RM izmeĊu dve mreţne barijere;
demilitarizovana zona, ili zaklonjena podmreţa, koja deli mreţnu
infrastrukturu na tri odvojene domene zaštite.
Primarni servisi zaštite: na osnovu primarnih kriterijuma podele
kontrola zaštite na upravljaĉke, operativne i tehniĉke, dele se na
upravljaĉke, operativne i tehniĉke servise.
Servisi zaštite: funkcije koje izvršava sistem implementiranih
upravljaĉkih, operativnih i tehniĉkih kontrola zaštite (ili sistem zaštite) u
skladu sa programom, politikama i procedurama zaštite; sve funkcije
implementiranog sistema zaštite neke raĉunarske mreţe koje taj sistem
treba da obezbedi korisnicima ili resursima mreţe; specificiraju se na
osnovu funkcionalnih i bezbednosnih zahteva za bezbednosne funkcije,
procene pretnji i faktora rizika, poverljivosti sadrţaja i procene
bezbednosti objekata IKT sistema.
Sveobuhvatni servisi zaštite: klasifikovani na osnovu kriterijuma
primarne funkcionalne namene i drugih elemenata za podršku
implementacije ukupnih bezbednosnih kapaciteta u IKT sistemu, dele se
na servise za: podršku, sprečavanje (zaštitu) i oporavak.
TTP (Trusted Third Party): poverljivi provajder/treća strana od
poverenja.

- 130 -
TTPS (Trusted Third Party Service): servis poverljivog provajdera
zaštite.

- 131 -
6. LITERATURA

1. Brown, S. Castell, G. Gray, P. Muller, "User Requirements

for Trusted Third Party Services", INFOSEC Project Report
S2101/01, Commission of the European Communities, DG
XIII, B-6, Oct 1993.
2. Grance T., Hash J., Stevens M., O‘Neal K., Bartol N., Guide
to Information Technology Security Services, NIST SP 800-
35, http://csrc.nist.gov/publications/nistpubs/800-35/sp800-
35.pdf, 2003.
3. ISO/IEC 17799:2000, Information Technology – Code of
practice for information security management,
http://www.iso.org, 2003.
4. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII.
decembar, 2005.
5. NIST SP 800-12, An Introduction to Computer Security: The
NIST Computer Security Handbook,
http://csrc.nist.gov/publications/nistpubs/800-12/sp800-12.pdf,
avgust 2003.
6. Purser S., A practical guide to managing information security,
Artech House, Boston, London, www.artechhouse.com, 2005.
7. RSA Data Security Conference, Functional Model TTPS
S2101/03 V1.1San Jose, CA, http://www.solutioncentre.nl,
1999.
8. Ruth A, Hudson K., Sertificat Security +, MicrosoftCo., CET
Beograd, 2004.
9. Stoneburner Gary, Underlying Technical Models for
Information Technology Security, NIST SP 800-33,
http://csrc.nist.gov/publications/nistpubs/800-33/sp800-33.pdf,
decembar 2003.
10. UK Department of Industry: A Taxonomic Model of Trusted
Third Party Services, Gamma Secure Systems, Diamond
House, Frimley Road, Camberley, 2002.
11. UK Department of Trade and Industry: Results of licensing of
Trusted Third Parties for the provision of encryption service,
www.brian.gladman, 1998.

- 132 -
8. TEHNOLOGIJE ZA ZAŠTITU RAĈUNARSKIH SISTEMA

0. UVOD

Po završetku ovog poglavlja razumećete:

- značaj tehnologije u sistemu zaštite RS i RM

- opštu podelu alata (mehanizama i protokola) za zaštitu
- osnovne alate za zaštitu RS
- koncept višeslojne zaštite

Rešavanje svakodnevnih problema zaštite zahteva dobro

poznavanje i primenu proceduralnih (operativno/upravljaĉkih) i
tehnoloških (tehničkih) komponenti - mehanizama i protokola zaštite.
Proceduralne i tehnološke komponente mogu se smatrati razliĉitim
aspektima istog rešenja. Naime, obiĉno nema smisla birati tehniĉke
mehanizme zaštite bez proceduralnih aspekata rešenja, a takoĊe, procese
zaštite treba projektovati prema tehnološkim mogućnostima i
raspoloţivim alatima da bi se obezbedio ţeljeni nivo podrške tom
procesu. Drugim reĉima, kombinacijom tehnika i alata i procedura
zaštite ostvaruje se efektivna arhitektura sistema zaštite.

Generička arhitektura sistema zaštite obuhvata najveći skup poznatih i

dostupnih proceduralnih i tehnoloških komponenti zaštite. Ovaj skup
komponenti zaštite menja se u zavisnosti od specifiĉnosti IKT sistema,
bezbednosnih zahteva i procene rizika u konkretnoj organizaciji.
Definisanje generiĉke arhitekture sistema zaštite sugeriše se u poĉetnoj
fazi razvoja ţivotnog ciklusa IKT sistema, a u fazi projektovanja sistema
zaštite arhitektura sistema zaštite se rafinira u skladu sa rezultatima
analize rizika, mogućnostima i potrebama organizacije.

U opštem sluĉaju, tehnologije (tehnike i alati) zaštite mogu se podeliti

host orijentisane (raĉunarskog sistema-RS) i mreţno orijentisane
(raĉunarskih mreţa-RM) mehanizme i protokole zaštite.

Mehanizmi zaštite su pojedinaĉni, individualni algoritmi, ili metodi, ili

hardversko-softverski moduli za eliminisanje bezbednosnih problema u
mreţi. U logiĉkom smislu, mehanizmi predstavljaju naĉin realizacije
servisa zaštite. Na primer: zaštita sadrţaja poruka u komunikacionom

- 133 -
kanalu je servis zaštite u RS/RM, a kriptografska transformacija sadrţaja
poruka je mehanizam za realizaciju servisa zaštite sadrţaja. Neki
mehanizmi zaštite su za jedan, a neki su univerzalni za više razliĉitih
servisa. Za realizaciju mehanizma zaštite jednog RS/RM, odnosno,
pojedinih servisa potrebno je obezbediti odreĊene kontrolne strukture
koje se nazivaju kontrole zaštite. Kontrole zaštite predstavljaju konaĉnu
(krajnju) klasifikaciju mehanizama zaštite.

- 134 -
1. KLASIFIKACIJA ALATA ZA ZAŠTITU

Za klasifikaciju tehniĉkih alata - mehanizama i protokola zaštite,

dobro je koristi klasifikacionu objektno-orijentisanu šemu za programe
zaštite IKT sistema (Sl. 1.1), [7].

ALATI ZAŠTITE

HOST MREŢNO
INFRASTRUKTURNI
ORIJENTISANI ORIJENTISANI
ALATI
ALATI ALATI

Autentifikacija Autentifikacija
PKI
i autorizacija i autorizacija

Smart kartice i
Integritet sistema Integritet mreţe
kriptografski
moduli

Kontrola pristupa
Kontrola pristupa
sistemu Autentifikacioni
RM
ureĎaji

Monitoring
Monitoring RM
sistema

Poverljivost i Poverljivost i
integritet podataka integritet RM

Sl. 1.1. Klasifikacija alata za zaštitu

Klasa host-orijentisanih alata za zaštitu namenjena je za poboljšanje
zaštite operativnih sistema-OS hosta (RS-servera ili radne stanice),
aplikacija i podataka. Klasa mrežno orijentisanih alata odnosi se
uglavnom na protokole za zaštitu raĉunarske mreţe-RM. Klasu alata za
infrastrukturnu podršku ĉine kompleksni, infrastrukturni alati za zaštitu i
veću funkcionalnu podršku IKT sistema. U odnosu na tipove servisa
zaštite koje podrţavaju i realizuju, unutar prve dve klase alati zaštite se
dalje klasifikuju na alate za:
1. autentifikaciju i autorizaciju (RS/RM),
2. zaštitu integriteta (RS/RM),
3. kontrolu pristupa (RS/RM),
4. monitoring sistema zaštite (RS/RM) i
5. zaštitu poverljivosti, integriteta i raspoloţivosti podataka i
informacija.

- 135 -
Prva ĉetiri servisa gledaju na RS ili RM kao na kontejnere podataka i
namenjeni su za zaštitu tih kontejnera u kojima se nalaze podaci i
informacije, dok poslednji servisi direktno štite poverljivost, integritet i
raspoloţivost podataka u RS.

Vaţno je razumeti razliku izmeĊu integriteta RS, RM i podataka. Mere

zaštite integriteta RS usmerene su da detektuju i potencijalno
spreĉe/oporave maliciozne modifikacije komponenti sistema, kao što su
izvršne datoteke. Mere zaštite integriteta RM namenjene su da obezbede
celovitost konfiguracije RM. Na primer, mehanizmi za zaštitu integriteta
RM mogu otkriti prisustvo neovlašćene mašine povezane na RM.
Mehanizmi za zaštitu integriteta podataka namenjeni su za zaštitu
nepromenljivosti podataka. Primer ovakvog servisa bio bi protokol
zaštite koji detektuje promene na podacima u toku prenosa.

- 136 -
2. HOST ORIJENTISANI MEHANIZMI ZAŠTITE

2.1. Bezbednosni slojevi raĉunarskog sistema

Za definisanje slojeva zaštite u RS koristi se slojevita struktura

apstraktnih nivoa u RS, sliĉno OSI modelu arhitekture, [9]. Dakle,
osnovni koncept slojevite zaštita poĉinje već u samom RS (Sl. 2.1).
Koncept slojevite arhitekture sistema zaštite obuhvata mreţnu
infrastrukturu, komunikacione protokole, aplikacije, RS i sistem
datoteka. Ovaj model koristi se samo za ilustrovanje osnovnog koncepta
zaštite RS. Operativni sistem (OS) je najznaĉajniji apstraktni sloj
sistemskih programa, zato što uĉestvuje u svim zadacima koje RS
obavlja. Zato, zaštita OS odreĎuje najviši nivo zaštite celog IKT sistema.
Naime, ako se OS kompromituje, samo je pitanje vremena kada će ceo
RS biti kompromitovan, pre svega sloj aplikacija iznad OS koji
komunicira direktno sa OS.

Aplikacije

Baza
Srednji sloj
podataka

Operativni sistem

Sl. 2.1. Apstraktni bezbednosni slojevi RS

Baze podataka i srednji sloj (middleware) su sistemski programi za

podršku OS, dok sloj aplikacija direktno pristupa OS. Sistemski programi
za podršku OS obezbeĊuju odreĊene standardne servise za brojni skup
aplikacija. Naime, osnovni koncept je da viši sloj programa prima neku
vrstu servisa od niţeg sloja programa. Primeri ovih programa su
relacione baze podataka i arhitektura brokera zahteva za zajedničke
objekte (middleware). Pošto ovi programi koriste servise koje nudi OS,
njihova zaštita je nuţno zavisna od zaštite OS i ako je OS probijen
direktno preko sloja aplikacija, obiĉno je trivijalno zaobići mehanizme
zaštite baza podataka i programa srednjeg sloja.

- 137 -
Primer 1: Relaciona baza ima zaštitu servisom kontrole pristupa (AC-
Access Contol), koju kontroliše administrativni nalog. Ako se na neki
naĉin dobije nalog superkorisnika koji ima pristup OS, onda je lako
dobiti pristup bazi podataka. Na sliĉan naĉin, zaštita aplikativnog sloja je
generalno zavisna od zaštite oba donja sloja (baza podataka i programa
srednjeg sloja).
Primer 2: Zašto je korisno upotrebljavati koncept slojevite zaštite?
Razmotrimo probleme koji prate zaštitu podataka uskladištenih na nekoj
platformi (RS) od ranjivosti programa OS. Jedna mogućnost je korišćenje
kriptozaštitnih mehanizama (šifrovanja baze podataka), ali takav
mehanizam mora ispuniti nekoliko jakih zahteva da bi se obezbedila
stvarna zaštita:

- kriptološki kljuĉevi moraju biti pohranjeni u ureĊaju otpornom

na proboj (smart kartica sa biometrijskim parametrom), da bi se
spreĉio korisnik sa administrativnim pravima da izvuĉe kljuĉeve
koristeći sistemske alate;
- dizajn treba da obezbedi da se podaci nikada ne pojavljuju u
otvorenom tekstu u memoriji RS ili sekundarnim memorijskim
ureĊajima (USB, CD, ...);
- interfejs izmeĊu OS i ureĊaja otpornog na proboj za skladištenje
kriptoloških kljuĉeva treba da bude zaštićen sa protokolom
zaštite da neovlašćeni korisnik sa administratorskim pravima, ne
moţe prisluškivati razmenu izmeĊu baze podataka i ureĊaja i
posle toga preko interfejsa prodreti u sistem.

Dakle, ko kontroliše OS obiĉno kontroliše sve što je aktivno iznad OS.

Zato dobar sistem zaštite poĉinje sa korektnom i dobrom zaštitom OS.

- 138 -
2.2. (Pod)sistem za zaštitu OS

Kako je OS osnovni apstraktni sloj softvera u RS, podsistem

zaštite prirodnog OS (NOSSS-Native Operation System Security
Subsystem) osnovni je sloj zaštite programa u RS. U tom smislu, dobro je
da drugi tipovi programa zaštite budu kompatibilni sa zahtevima NOSSS,
a ne obrnuto. U razvoju strategije programa zaštite, treba
komplementarno jaĉati zaštitu NOSSS programa dodavanjem drugih
tipova programa za zaštitu, vodeći raĉuna da uvedeni mehanizmi zaštite
ne budu u konfliktu sa NOSSS alatima zaštite. Karakteristike NOSSS
programa za zaštitu priliĉno su standardne i obiĉno ukljuĉuju osnovne
mehanizme zaštite kao što su mehanizmi kontrole pristupa datotekama i
objektima RS, mehanizmi autentifikacije korisnika samom OS i
mehanizmi logovanja bezbednosno relevantnih dogaĎaja. Naĉini
implementacije ovih mehanizama razlikuju se u zavisnosti od vrste
platforme, pa je teško definisati homogene zahteve za brojne platforme.
Glavna opasnost od prevelikog korišćenja univerzalnih programa za
zaštitu koje proizvode poverljivi provajderi (TTP) je udaljavanje korisnik
od NOSSS mehanizama, koji se mogu do te mere zanemariti da se uopšte
i ne koriste. Drugi nedostatak korišćenja univerzalnih programa za zaštitu
namenjenih za heterogene platforme je dovoĊenje u zabludu
administratora zaštite, koji obiĉno iskljuĉe NOSSS zaštitu, a da pri tome
dodatni program za zaštitu uopšte ne podrţava neku funkciju zaštite
NOSSS zaštitnog programa.

Neki TTP provajderi nude poverljive OS zasnovane na kriterijumima

evaluacije poverljivih raĉunarskih sistema (TCSEC – Tusted Computer
System Evaluation Criteria). Za korišćenje TCSEC treba poznavati
kriterijume prema kojima je sistem evaluiran i tip rizika kojeg otklanja.
Dalje, taj rizik treba evaluirati u kontekstu sistema koji se razmatra.
Konaĉno, korišćenje TCSEC programa za ekstra zaštitu ĉesto ide po cenu
redukcije funkcionalnosti tako da se neke aplikacije uopšte ne mogu
izvršavati na tom sistemu.

- 139 -
2.3. Autentifikacija i autorizacija

Autentifkacija i autorizacija: Autentifikacija je proces sa kojim

korisnik (lice ili program) dokazuje svoj identitet sistemu ili aplikaciji
koji nude neki servis. Autorizacija je proces dodeljivanja legalnim
korisnicima prava pristupa objektima IS, a moţe biti obavezna (MAC-
Mandatory Access Control)), diskreciona (DAC-Descretionary Access
Control) ili na osnovu uloga (RBAC-Role Based Access Controle), [9]. U
DAC modelu vlasnik sistema upravlja kontrolom pristupa na osnovu
svojih odluka, a u MAC i RBAC modelima kontrola pristupa reguliše se
na osnovu utvrĊenih pravila. U poslovnim sistemima najĉešće se koristi
RBAC metod, gde se korisnici prema ulogama i odgovornostima na poslu
grupišu u jedinstvene grupe, sa istim privilegijama svih ĉlanova grupe.
Korisnici se dodaju ili uklanjaju iz grupe u procesu administracije servisa
kontrole pristupa. Jedan korisnik moţe biti ĉlan više grupa, sa
privilegijama te grupe i posebnom efektivnom dozvolom za druge grupe
(npr., nadzornik). Ako su privilegije u konfliktu, zavisi od OS i sistema
prioriteta koje privilegije će preovladati. Sa zahtevom za autentifikaciju
sistemi mogu restriktivno davati svoje servise samo onim korisnicima
koji su za njih ovlašćeni (autorizovani). Za dalju restrikciju pristupa, ako
je potrebno mogu se koristiti tehnike servisa kontrole pristupa – AC
(Access Controle) koji obuhvata mehanizme identifikacije, autentifikacije
i autorizacije (Sl.2.2.). Treba zapaziti da se AC oslanja na to da proces
autentifikacije verifikuje priloţeni identitet korisnika (korisniĉko ime,
pasvord i dr.).

- 140 -
 Korisnici

Computer

Korisnički profili
Identifikacija

zaštite

Autentifikacija
AC datoteka

Audit log
datoteka
Autorizacija

izveštaja
Pisač
Baza Programske
podataka biblioteke
Izveštaj

Sl. 2.2. Generiĉki servis kontrole pristupa

Pošto većina korisnika u organizacijama danas pristupaju sistemima i

aplikacijama preko lokalne mreţe (LAN), ili udaljenom konekcijom,
autentifikacija korisnika smatra se mreţnim procesom. Standardni
mehanizmi za autentifikaciju su autentifikacioni protokoli i ureĎaji
(biometrijski, tokeni, smart kartice,...).

Privilegovani menadžerski nalog obezbeĊuje administratoru sistema da

odreĊenim korisnicima daje na kontrolisan naĉin mogućnost da koriste
neke selektivne komande pod administratorskim nalogom, a da pri tome
ne deli svoj nalog sa tim korisnicima. U tom smislu, privilegovani
menadţerski nalog se koristi da obezbedi zaštitu OS, a ne da obezbedi
rad sa programima za podršku ili sa slojem aplikacija.

U cilju razumevanja osnovnih razlika tri kljuĉna metoda za

autentifikaciju (MAC, DAC, RBAC),u Praktikumu udţbenika razvijena
je Vežba GI P8A u kojoj treba prepoznati i razlikovati kljuĉne
karakteristike pomenutih procesa autentifikacije. U Vežbi GI P8B
analiziran je detaljno RBAC metod autentifikacije sa zahtevom za
konkretnu primenu usvojenih znanja kroz praktiĉan rad, a u cilju
razumevanja prednosti i nedostataka metoda RBAC autentifikacije u

- 141 -
servisu kontrole pristupa raĉunarskom sistemu. Da bi se razumela
potreba kvalitetnog upravljanja pasvordom i znaĉaj upotrebe jakog
(kompleksnog) pasvorda u procesu identifikacije i autentifikacije
korisnika operativnom sistemu (OS) u servisu kontrole pristupa,
razvijena je Vežba GI P8C sa zadatkom da studenti ovladaju procesom
upravljanja pasvordom.

2.4. Integritet raĉunarskog sistema

Integritet raĉunarskog sistema kontrolišu skeneri sistema zaštite,

koji se obiĉno dele na: skenere zaštite RS i skenere zaštite RM.

2.4.1. Skeneri zaštite RS

Skeneri zaštite raĉunarskog sistema rade na principu periodiĉnog

monitorisanja aktuelne konfiguracije platforme ĉija se ranjivost skenira i
poreĊenjem ove konfiguracije sa ţeljenom, odnosno predefinisanom
osnovnom konfiguracijom koja se smatra idealnom za datu platformu.
Iako skeneri zaštite mogu raditi na svim apstraktnim nivoima, u praksi su
retki skeneri zaštite na aplikativnom nivou, pošto zahtevaju detaljno
poznavanje aplikacije koja se skenira. U praksi glavna je upotreba
skenera ranjivosti zaštite samog OS.

Skeneri zaštite uglavnom se koriste u okruţenju IKT sistema manjeg

obima, pošto bezbednost ovih sistema obiĉno zavisi od korektnosti
podešavanja velikog broja opcija konfiguracije. Zavisno od OS moguće
je uskladištiti datoteku osnovne i druge konfiguracije na brojne lokacije u
sistemu, pa im je teško manuelno pratiti trag. Naţalost male promene u
većini ovih opcija mogu imati drastiĉan uticaj na ukupan nivo zaštite
sistema, a te se promene mogu dogoditi iz više razloga:

- ljudske greške, na primer kada sistem administratori rade pod

pritiskom;
- neznanja, na primer korisnici UNIX OS mogu instalirati
odreĊene datoteke poznate kao .rhost u liĉnim direktorijima da
omoguće pristup administratorskom nalogu drugim korisnicima,
što je poznat izvor problema za administratore;
- posledica instalacije novog programa, što nije neobiĉno za
aplikativne programe da zahtevaju nepoţeljne opcije
konfiguracije za korektno funkcionisanje.

- 142 -
U IKT sistemima srednjeg i velikog obima, gotovo je nemoguće
upravljati ovolikom kompleksnošću bez automatizovanih alata. Na slici
Sl. 2.3. ilustrovano je kako se koriste skeneri zaštite za osiguranje
bezbednog okruţenja.

Aktuelna Ciljna
konfiguracija konfiguracija Kontrolna
Upravljačka
stanica
stanica

Softverski
agent
Izveštaj

Sl.2.3. Korišćenje skenera ranjivosti u IS srednje veliĉine

Tipiĉna implementacija obuhvata: softverskog agenta koji skenira niz

ciljnih platformi i verifikuje aktuelnu konfiguraciju u odnosu na ciljnu;
upravljačku stanicu koja skuplja podatke sa svih skeniranih platformi u
RM i kontrolnu stanicu koja koristi softver korisniĉkog interfejsa za
generisanje izveštaja. Administrator koristi klijentski interfejs da pristupa
rezultatima skeniranja. Softverski agent je obiĉno specifiĉan za OS i
obiĉno dolazi sa prekonfigurisanom bazom podataka uobiĉajenih
ranjivosti i izborom predefinisanih politika. Ovi predefinisani parametri
koriste se kao poĉetne vrednosti za definisanje osnovne zaštite i politike
skeniranja za specifiĉnu lokaciju. Vendori obiĉno nude aţuriranje
softvera za skeniranje. Ovi alati mogu imati dodatne funkcionalnosti, kao
što su zaštita lozinkom i mogućnost monitorisanja promene sadrţaja (na
primer, skladištenjem hešovanih datoteka). Alati za skeniranje poznatih
ranjivosti hosta mogu se naći na web adresi [4].

Komercijalni skeneri zaštite mogu prezentirati otkrivena odstupanja od

ciljne konfiguracije u formi izveštaja i grafiĉkog prikaza. Neki alati imaju
mogućnost automatske korekcije stanja, što je delikatna operacija, jer
korekcija ranjivosti sistema zaštite moţe imati glavni uticaj na
funkcionisanje sistema.

- 143 -
 Kljuĉno pitanje o efektivnosti skenera zaštite je u kojoj meri redukuju
rizik, što zavisi od dva faktora:

1. mere u kojoj osnovna konfiguracija zaštite predstavlja ţeljeni

profil rizika i
2. efikasnosti procesa korekcije koji sledi nakon otkrivanja
ranjivosti.

Ako su ova dva faktora korektno upravljana, skeneri zaštite mogu

obezbediti mnogo dodatnih kontrola u distribuiranom IKT sistemu.

2.4.2. Antivirusni programi

Kompjuterski virusi i drugi maliciozni programi predstavljaju

pretnju za integritet raĉunarskog sistema, pošto uglavnom rade tako što
se instaliraju na lokalnoj platformi, a zatim je koriste za dalju
propagaciju.

Koncept antivirusnog programa jednostavan je za razumevanje. Svaki put

kada se maliciozni program otkrije, ispituje se u cilju identifikovanja dela
strukture koji je osoben za taj kôd. Ovaj elemenat strukture smatra se
potpisom (definicijom) malicioznog programa i moţe se kasnije koristiti
za detekciju prisustva poznatih malicioznih kôdova. Antivirusni programi
jednostavno rade tako što skenira OS, baze podataka i aplikacije, traţeći
potpise malicioznih kôdova uskladištenih u bazi podataka definicija.
Kada se otkrije maliciozni kôd sa poznatom definicijom aktivira se set
instrukcija za uklanjanje te definicije.

U stvarnosti zadatak antivirusnih programa mnogo je sloţeniji, pošto

autori malicioznih kôdova nalaze brojne naĉine da poraze ovaj
jednostavni odbrambeni mehanizam. Takve tehnike su korišćenje
kriptozaštite za skrivanje potpisa (definicija) malicioznih kôdova. Zbog
toga su savremeni antivirusni programi dizajnirani tako da rade i na
aplikativnom sloju i sloju OS i da mogu skenirati veliki obim objekata,
kao što su memorije, datoteke i dodaci datoteka, e-pošta i but sektori.
Osim toga, skeniranje nije ograniĉeno na jednostavnu detekciju definicija
malicioznih programa, nego mogu ukljuĉivati napredne tehnike kao što
su dešifrovanje i uklanjanje u izolovan prostor (karantin).

- 144 -
2.4.3. Skeneri sadržaja

Skeneri sadrţaja su komplementarni antivirusnim programima.

Analiziraju sadrţaje poruka, e-pošte ili sadrţaje preuzete sa Interneta,
evaluiraju ih u odnosu na predefinisane politike zaštite, a zatim
izvršavaju neke akcije kada sadrţaj ne ispunjava zahteve politika zaštite.

Pošto skeneri sadrţaja obiĉno ispituju objekte koji su u prenosu izmeĊu

dva sistema, oni rade na aplikativnom nivou. Ovaj pristup je potencijalno
moćniji od antivirusne detekcije bazirane na potpisu, zato što moţe
ugraditi pravila bazirana na razliĉitim kriterijumima i nisu ograniĉeni na,
u suštini statiĉka svojstava objekata malicioznih programa.

Programi za filtriranje sadrţaja variraju mnogo po obimu i sofistikaciji.

Oni se kreću od jednostavnih skenera sadrţaja e-pošte koji mogu vršiti
leksiĉku analizu i odlagati u karantin poruke koje sadrţe odreĊene
(predefinisane) reĉi ili fraze, do sofisticiranih skenera sadrţaja koji u
realnom vremenu ispituju dolazne poruke i preuzete sadrţaje sa Interneta.
Ovo je posebno znaĉajno za bezbednosnu proveru prisustva mobilnih
kodova (Java, JavaSkript i ActiveX).

Većina skenera sadrţaja obezbeĊuje nekoliko naĉina reagovanja na

povredu politike zaštite i omogućava administratoru da konfiguriše
odgovarajuće akcije na bazi od pravila. U sluĉaju e-pošte, skeneri
sadrţaja mogu odlagati u karantin ili izbrisati dodatke porukama ili
odbaciti poruku u celini u junk direktorijum. Skeneri sadrţaja mobilnih
kodova mogu blokirati preuzeti sadrţaj, preneti sumnjivi sadrţaj TTPS
provajderu (poverljivom provajderu zaštite) na analizu, izvršiti logovanje
i potencijalno poslati alarm korisniku. Neki web filteri mogu prepoznati i
odgovoriti na sadrţaj. Filteri e-pošte imaju ugraĊene antivirusne
programe, a antivirusni programi poĉinju ugraĊivati neke od
funkcionalnosti skenera sadrţaja, što navodi na zakljuĉak da ova dva
mehanizma zaštite konvergiraju u jedinstven proizvod.

- 145 -
2.5. Kontrola pristupa raĉunarskom sistemu

2.5.1. Mehanizmi za upravljanje pristupom

Softverski mehanizmi za upravljanje pristupom koriste se za

upravljanje pravilima prema kojima korisnici mogu pristupiti objektima
sistema. Razlikuju se:

 softverski mehanizmi za kontrolu pristupa mainfraim

raĉunarima, pošto većina savremenih OS ukljuĉuje ove
funkcionalnosti u NOSSS i
 univerzalna rešenja za kontrolu pristupa za razliĉite platforme,
poznata kao administracija korisnika organizacije (EUA-
Enterprise User Administration), koji mogu interaktivno raditi sa
postojećim NOSSS karakteristikama na većini platformi, a cilj
im je da centralizuju upravljanje kontrolom pristupa u
distribuiranom okruţenju.

Mainframe mehanizmi za kontrolu pristupa su meĊu najstabilnijim

savremenim programima zaštite na trţištu i traju skoro 30 godina. Ovaj
mehanizam zaštite povećava bezbednost sloja OS, dobro je poznat i
sadrţi tipiĉno sledeće funkcionalnosti:

 autentifikaciju korisnika;
 obezbeĊuje okvir za zaštitu objekata sistema, koji omogućava
administratoru da definiše prava pristupa korisnika ili grupa
korisnika odreĊenim objektima;
 obezbeĊuje interfejs koji omogućava aplikacijama da
interaktivno rade sa programom i koriste funkcionalnosti
autentifikacije i upravljanja pristupom;
 obezbeĊuje verifikaciju nivoa ovlašćenja (autorizacija) i kontrole
pristupa i
 obezbeĊuje generisanje kontrolnih tragova.

EUA softverski mehanizmi, nasuprot mainframe mehanizmima za

kontrolu pristupa, razvijeni su za rešavanje problema koji prate
upravljanje sa pravima pristupa velikom broju OS, bazama podataka i
aplikacijama sa sopstvenim modelom zaštite.

- 146 -
Ovi problemi ukljuĉuju:

 teškoću dobijanja pregleda AC podataka iz više mašina i

softverskih proizvoda;
 potrebu izvršavanja promena na korisniĉkim nalozima i pravima
pristupa na svakom sistemu, što je vremenski zahtevano i sklono
stvaranju grešaka;
 ograniĉeno kretanje administratora sa jednog do drugog tipa
raĉunarskog sistema, zbog potrebe da poseduje administratorska
iskustva i struĉnost za svaki poseban sistem;
 neefikasan tok procesa autorizacije sa niskim nivoom
automatizacije.

EUA program je namenjen da obezbedi centralnu administraciju za

upravljanje pravima pristupa svim slojevima softvera na razliĉitim
platformama. Vaţno je uoĉiti da EUA softver obezbeĊuje interfejs za
upravljanje razliĉitim oblastima postojećih AC mehanizama, ali ne
implementiraju direktno sam AC mehanizam u OS.

Najĉešće rešenje arhitekture EUA softvera sliĉno je onom kojeg koriste

host orijentisani skeneri zaštite i ukljuĉuje softverskog agenta koji radi na
ciljnoj platformi, upravljaĉku aplikaciju koja moţe komunicirati sa
agentom i softver korisniĉkog interfejsa. Upravljanje (kreiranje,
modifikacija ili ukidanje) naloga korisnika moţe se vršiti direktno na
ciljnoj platformi ili preko jedne administrativne taĉke u EUA.
Konzistentnost centralne baze podataka koju odrţava EUA sistem,
obezbeĊuje se dijalogom izmeĊu EUA agenta i upravljaĉke aplikacije.
Proces sinhronizacije ovog dijaloga razlikuje se od proizvoda do
proizvoda i moţe ukljuĉivati sinhronizaciju u realnom vremenu ili
pomoću batch procesa (u kojem se skup programa izvršava u raĉunaru u
isto vreme), u kojem sluĉaju postoji „prozor rizika― (bez sinhronizacije),
što moţe dovesti do nekorektne administrativne odluke.

Agentski softver obiĉno je instaliran kao aplikacija koja radi na vrhu

NOSSS na ciljnoj platformi, ili kao eksterni softver za kontrolu pristupa
u sluĉaju mainframe OS. Neki softverski paketi nude API (Application
Programming Interface) koji omogućava podršku sopstvenim autorskim
aplikacijama korisnika. Jedna posledica korišćenja udaljenog softverskog
agenta je da odreĊena implementacija moţe da ne podrţava sve

- 147 -
funkcionalnosti originalnog OS. Ovo je sluĉaj koji moţe stvoriti ranjivost
za obaranje sistema. Komunikacija izmeĊu centralno upravljanog sistema
i softverskog agenta obiĉno se štiti kriptografskim tehnikama, da bi se
spreĉila modifikacija podataka u prenosu.

Alternativni pristup korišćenju EUA programa je adaptacija meta-baze

podataka za centralizaciju AC podataka. Ovo rešenje, meĊutim, ne deli
bezbednosno relevantne podatke od drugih personalnih podataka i ne
obezbeĊuje integraciju sa postojećim sistemima na naĉin kako to ĉini
EUA program.

2.6. Monitoring zaštite raĉunarskih sistema

2.6.1. Detektori upada u računarski sistem

Detektori upada u raĉunarski sistem - IDS (Intrusion Detection

Systems) koriste se za prepoznavanje indikacija nekog pokušaja upada i
da upozore korisnika ili izvrše korektivne akcije, [6], [10]. Savremeni
koncept IPS (Intrusion Prevention Systems) sistema omogućava, pored
funkcija IDS, odreĊene vrste inteligentnih zamki za napadaĉa (tipa ćupa
meda-hony pot), kojima skreću njihovu paţnju i izuĉavaju osobenosti u
cilju preventivne zaštite od sledećeg napada, (Sl. 2.4).

Napadač

Monitoring
Simulirano program
okruţenje

Log
Ţrtvovana datoteka
mašina

Sl. 2.4. IPS koncept

- 148 -
Postoje dve velike klase IDS sistema:

 mreţni IDS ili NIDS i

 host IDS ili HIDS.

Oba sistema analiziraju podatke o dogaĊaju na znakove upada, ali se

razlikuju naĉini na koji to rade i tipovi informacija koje procesiraju.
Prednosti i nedostaci su sliĉni onima kod skenera zaštite.

IDS sistemi se, takoĊe, mogu klasifikovati prema principima detekcije

na:
 sisteme koji koriste tehniku detekcije na bazi potpisa i
 sloţene detektore anomalija.

Prvi uporeĊuju log datoteku poznatih potpisa napada sa stvarnim, dok

drugi traţe anomalije prema obrascima koje koriste sistemi.

HIDS sistemi mogu koristiti razliĉite mehanizme da detektuju moguće

upade. Danas, ovi softveri imaju tendenciju da koriste tehnike kao što su
pseudorelaciona analiza kontrolnih tragova i provera integriteta datoteka.
Neki proizvodi kombinuju mehanizme potpisa i detekciju anomalija i
omogućavaju brzo aţuriranje baza potpisa (definicija) napada. HIDS
programi obiĉno su dizajnirani za odreĊene OS koji pruţaju maksimum
mogućih funkcionalnosti kao što su direktna intercepcija i interpretacija
pristupnih poziva sistemu. Glavna ranjivost HIDS sistema koji zavise od
informacija kontrolnih tragova je mogućnost proboja u log datoteku i
modifikacija informacija.

HIDS sistemi obiĉno rade i sa šifrovanim podacima, koje ciljni host

dešifruje pre procesiranja. HIDS i NIDS sistemi generalno imaju dobre
sisteme izveštavanja sa razliĉitim nivoima detalja i grafiĉkim displejom
informacija.

- 149 -
2.6.2. Mehanizmi za upravljanje log datotekama
Mehanizmi za upravljanje log datotekama koriste se da obezbede
selektivan pristup log datotekama kontrolnih tragova bezbednosno
relevantnih dogaĊaja. U okruţenju sa razliĉitim platformama, ovi
mehanizmi pomaţu osetljivi proces skupljanja i kombinovanja login
informacija sa razliĉitih platformi, što omogućava administratoru da prati
napade ili sumnjive dogaĊaje koji pogaĊaju više od jednog hosta. Pošto
većina savremenih OS obezbeĊuje log informacije, mehanizmi za
upravljanje log datotekama koriste se za obezbeĊenje zaštite svim
slojevima softvera u raĉunarskom sistemu.
Izvlaĉenje relevantnih podataka iz kontrolnih log datoteka u srednjim i
velikim organizacijama, veoma je sloţen i vremenski zahtevan posao.
Obiĉno nije problem samo skupljanje informacija, mada dobro treba
razmisliti koje dogaĊaje upisivati u log datoteke za svaku datu aplikaciju.
Pod pretpostavkom da je ovo uĉinjeno korektno, postoje brojni problemi
za korišćenje informacija sadrţanih u log datotekama:

 obiĉno postoji veliki obim podataka koje treba analizirati;

 zahtevana su jasna pravila koja indiciraju koje podatke treba
analizirati proaktivno, a koji podaci se analiziraju reaktivno,
samo kao odgovor na sumnjiv incident;
 zahteva se smeštanje informacija kontrolnih tragova u kontekstu
brojnih platformi da bi se pratile sumnjive aktivnosti koje se
šire kroz mreţu.
Mehanizmi za upravljanje log datotekama smanjuju problem obima
podataka kontrolnih tragova, obezbeĊujući filtriranje podataka, na
osnovu implementiranog skupa pravila za selekciju podskupa podataka
izvan skupa podataka od interesa. Nedostaci filtracije log podataka su
višestruki:
1. Neke vaţne informacije mogu se potpuno odstraniti tako da ne
uĉestvuju u analizi.
2. Kako se podaci istog tipa predstavljaju na razliĉitim platformama,
mehanizmi za upravljanje log datotekama moraju biti dovoljno
inteligentni da ih prepoznaju. Idealno bi bila standardizacija
reprezentacije kontrolnih tragova (što je i cilj projekta COAST
Audit Trail Reduction Group-e), [3], što bi omogućilo

- 150 -
 administratorima da vrše analizu, a ne da interpretiraju sirove
podatke.
3. Potrebno je da se u log datotekama oznaĉavaju tragovi koji su
namenjeni za proaktivnu ili reaktivnu analizu.
4. U većini sistema vreme ĉasovnika razliĉitih platformi samo je
pribliţno sinhronizovano. Postoje protokoli za automatsku
sinhronizaciju ĉasovnika na razliĉitim platformama (na primer,
NTP-Network Sinhronization Protocol), ali oni nisu uvek
implementirani u mreţama. Problem sinhronizacije ĉasovnika
moţe uticati na procese konsolidacije hronologije napada, kao i
na podatke prezentirane filterima log podataka.

Većina savremenih rešenja samo delimiĉno rešava ove probleme. Većina

alata za analizu log datoteka web lokacija danas su sofisticirani i sloţeni,
ali nisu usmereni na bezbednosne dogaĊaje, nego na informacije koje se
odnose na posete klijenata lokaciji.

- 151 -
2.7. Mehanizmi za zaštitu poverljivosti i integriteta podataka

2.7.1. Kriptografski mehanizmi

Kriptografski mehanizam je u suštini tehnika skrivanja

informacija pomoću neke transformacije na takav naĉin da je samo
odreĊena grupa korisnika moţe izvući u originalnom tekstu, a svi drugi
ne mogu.

Ovo se koristi upotrebom neke vrste kljuĉa sa kojim se vrši

transformacija. Ovlašćeni korisnici obezbeĊeni su sa istim kljuĉem
(simetriĉna kriptografija) ili drugim odnosnim kljuĉem iz para javnog i
privatnog kljuĉa (asimetriĉna kriptografija ili PKI-Public Key
Infrastructure), za izvlaĉenje originalne informacije iz šifrata. U
savremenim kriptografskim sistemima bezbednost je više u kljuĉu nego u
algoritmu, jer je praktiĉno nemoguće ĉuvati u tajnosti algoritam u
komercijalnom okruţenju, dok je ĉuvanje tajnosti kljuĉa samo problem
procesa upravljanja kriptografskim kljuĉem, [11].

Kriptografski mehanizmi koriste se u arhitekturi sistema zaštite za

implementaciju odreĊenih integralnih specifiĉnih servisa zaštite:
autentifikacije, poverljivosti, integriteta i neporecivosti informacija. U
sistemu zaštite radne stanice, kriptografski mehanizmi se uglavnom
koriste za zaštitu integriteta i poverljivosti podataka i informacija.
Zahtevi za kriptografsku autentifikaciju i neporecivost mnogo su ĉešći za
mreţno okruţenje.

Kriptografske tehnike za zaštitu poverljivosti podataka najzastupljeniji su

kriptografski mehanizmi. Mogu se primenjivati za šifrovanje celog
ĉvrstog diska (n.p.r., LapTop ili portabilni raĉunarski sistem), baza
podataka, ili datoteka.

Manje oĉigledna primena kriptografskih mehanizama je za zaštitu

integriteta podataka. Ideja je da se od originalnih podataka napravi hash
otisak ili MD (Massage Digest), koji se zatim šifruju i skladište na
bezbednom mestu, [8]. Ako neovlašćeni korisnik izmeni podatke, ne
moţe se rekonstruisati originalna hash funkcija ili MD iz šifrata, što pak
vlasnik moţe dokazati verifikacijom jer poseduje neophodan kljuĉ.
Skeneri zaštite ĉesto koriste ovu tehniku za detekciju modifikacije
datoteka.

- 152 -
2.7.2. Skeneri sadržaja i e-mail filteri

Skeneri sadrţaja i e-mail filteri mogu analizirati sadrţaj preuzetih

mobilnih kodova ili e-mail poruka za detekciju potencijalne povrede
sistema zaštite i izvršavanje akcije odgovora na pretnje. Ove
funkcionalnosti su korisne za zaštitu integriteta OS. Iste tehnike mogu se
koristiti i za zaštitu integriteta podataka. Na primer, legalni korisnik
razmenjuje pornografski materijal sa serijom kontakata izvan
organizacije. To radi ugradnjom slike ili teksta u e-mail poruke. Skeneri
sadrţaja mogu detektovati ugraĊene slike, interpretirati tekst i smestiti ih
u karantin za dalju analizu. U ovom primeru, softveri skenera sadrţaja
direktno se koriste za zaštitu samih podataka.

- 153 -
3. REZIME

Za klasifikaciju tehniĉkih alata - mehanizama i protokola zaštite

koristi se klasifikaciona objektno-orijentisana šema za softvere zaštite
IKT sistema. Klasifikacija obuhvata tri klase alata: host-orijentisane
mehanizme zaštite, namenjene za poboljšanje zaštite operativnih sistema-
OS hosta (RS-raĉunarskog sistema, servera ili radne stanice), aplikacija i
podataka.; mrežno orijentisane alate (mehanizme i protokole) za zaštitu
raĉunarske mreţe-RM i mehanizmi za infrastrukturnu podršku, kao što su
infrastruktura sa javnim kljuĉem (PKI), smart kartice i autentifikacioni
ureĊaji. Unutar prve dve klase, mehanizmi zaštite dalje se klasifikuju u
odnosu na servise zaštite koje podrţavaju i realizuju na: autentifikacija i
autorizacija (RS ili RM), zaštita integriteta (RS ili RM), kontrola
pristupa (RS ili RM), monitoring (RS ili RM), servisi zaštite
poverljivosti, integriteta i raspoloživosti podataka i informacija. U ovoj
klasifikaciji vaţno je razumeti razlike izmeĊu integriteta RS, RM i
podataka.

Model troslojne strukture apstraktnih nivoa u RS (sliĉno OSI modelu)

koristi se za definisanje bezbednosnih slojeva (slojeva zaštite) u RS. Ovaj
model koristi se samo za ilustrovanje osnovnog koncepta zaštite RS.
Operativni sistem (OS) je najznaĉajniji apstraktni sloj sistemskih
programa (softvera) zato što uĉestvuje u svim zadacima koje RS obavlja.
Zato, zaštita OS odreĎuje najviši nivo zaštite celog IKT sistema. Naime,
ako se OS kompromituje, samo je pitanje vremena kada će ceo IKT
sistem biti kompromitovan, pre svega sloj aplikacija iznad OS.

Baze podataka i srednji sloj (middleware) iznad sloja OS su sistemski

programi za podršku OS, dok viši sloj aplikacija direktno pristupa OS.
Osnovni koncept modela je da viši sloj softvera prima neku vrstu servisa
od niţeg sloja softvera. Tako sistemski programi za podršku
(middleware) obezbeĊuje odreĊene standardne servise za brojni skup
aplikacija. Pošto ovi softveri koriste servise koje nudi OS, njihova zaštita
je nuţno zavisna od zaštite OS i ako je OS probijen direktno preko sloja
aplikacija, lako je zaobići mehanizme zaštite baza podataka i softvera
srednjeg sloja. Zato je podsistem zaštite prirodnog OS (NOSSS-Native
Operation System Security Subsystem) osnovni sloj zaštite softvera u RS.
U razvoju strategije softverske zaštite, treba komplementarno jaĉati
zaštitu NOSSS softvera dodavanjem drugih tipova zaštite softvera,

- 154 -
vodeći raĉuna da uvedeni mehanizmi zaštite ne budu u konfliktu sa
NOSSS zahtevima.

Autentifikacija je proces sa kojim korisnik (lice ili program) dokazuje

svoj identitet sistemu ili aplikaciji koji nude neki servis. Standardni
mehanizmi za autentifikaciju su autentifikacioni protokoli i ureĎaji
(biometrijski, tokeni, smart kartice,...). Autorizacija je proces
dodeljivanja legalnom korisnicima prava pristupa objektima IS.
Autentifikacija i autorizacija su deo jedinstvenog procesa – servisa
kontrole pristupa, koji se oslanja na proces autentifikacije da verifikuje
identitet korisnika. Klasiĉni mehanizmi za kontrolu pristupa, preuzeti iz
mainframe raĉunara, su kontrolne liste pristupa (ACL), matrica pristupa
na osnovu uloga i odgovornosti, korisniĉki nalog i lozinka. Savremeni
softverski mehanizmi za logiĉku kontrolu pristupa su univerzalna rešenja
za kontrolu pristupa za razliĉite platforme, poznata kao administracija
korisnika organizacije (EUA-Enterprise User Administration), koji mogu
interaktivno raditi sa postojećim NOSSS karakteristikama na većini
platformi, a cilj im je da centralizuju upravljanje kontrolom pristupa u
distribuiranom okruţenju.

Servis monitoringa (nadzora) sistema zaštite RS, izvršavaju detektori

upada u RS (IDS- Intrusion Detection Systems), koji prepoznavaju
indikacije pokušaja upada, upozoravaju korisnike ili vrše korektivne
akcije. IDS sistemi (HIDS-za RS i NIDS-za RM) mogu se klasifikovati
prema principima detekcije na sisteme koji koriste tehniku detekcije na
bazi potpisa i sloţene detektore anomalija. Savremeni koncept IPS
(Intrusion Prevention Systems) sistema omogućava, pored funkcija IDS,
odreĊene vrste inteligentnih zamki za napadaĉa (tipa ćupa meda-hony
pot), kojima skreću njihovu paţnju i izuĉavaju osobenosti u cilju
preventivne zaštite od sledećeg napada.

Mehanizmi za upravljanje log datotekama koriste se da obezbede

selektivan pristup log datotekama kontrolnih tragova bezbednosno
relevantnih dogaĊaja. Mehanizmi za upravljanje log datotekama
smanjuju problem obima podataka kontrolnih tragova, obezbeĊujući
filtriranje podataka, na osnovu implementiranog skupa pravila sa
selekciju podskupa podataka izvan skupa podataka od interesa.
Standardizacija reprezentacije kontrolnih tragova (cilj projekta COAST
Audit Trail Reduction Group-e), omogućava administratorima da vrše
analizu, a ne da interpretiraju sirove podatke.

- 155 -
Integritet RS kontrolišu skeneri sistema zaštite, koji se obiĉno dele na:
skenere zaštite RS i skenere zaštite RM. U praksi glavna je upotreba
skenera ranjivosti zaštite samog OS. Skeneri zaštite uglavnom se koriste
u okruţenju IKT sistema manjeg obima. U IKT sistemima srednjeg i
velikog obima, gotovo je nemoguće upravljati ovolikom kompleksnošću
bez automatizovanih alata. Skeneri zaštite raĉunarskog sistema rade na
principu periodiĉnog monitorisanja aktuelne konfiguracije platforme ĉija
se ranjivost skenira i poreĊenjem ove konfiguracije sa ţeljenom, odnosno
predefinisanom osnovnom konfiguracijom koja se smatra idealnom za
datu platformu.

Kompjuterski virusi i drugi maliciozni programi narušavaju integritet RS,

pošto uglavnom šire tako što se instaliraju na lokalnoj platformi, a zatim
je koriste za dalju propagaciju. Antivirusni programa, svaki put kada
otkrije maliciozni program, ispituje ga da identifikuje deo strukture
osobene za taj kôd, koji se smatra potpisom (definicijom) malicioznog
programa i kasnije se koristiti za detekciju prisustva poznatih malicioznih
kôdova. Antivirusni programi jednostavno rade tako što skenira OS, baze
podataka i aplikacije, traţeći potpise malicioznih kôdova uskladištenih u
bazi podataka definicija. Kada se otkrije maliciozni kôd sa poznatom
definicijom aktivira se set instrukcija za uklanjanje te definicije. U
stvarnosti zadatak antivirusnih programa mnogo je sloţeniji, pošto pisci
malicioznih kôdova nalaze brojne naĉine da poraze ovaj jednostavni
odbrambeni mehanizam.

Skeneri sadrţaja su komplementarni antivirusnim programima.

Analiziraju sadrţaje poruka, e-pošte ili sadrţaje preuzete sa Interneta,
evaluiraju ih u odnosu na predefinisane politike zaštite, a zatim
izvršavaju neke akcije kada sadrţaj ne ispunjava zahteve politika zaštite.

Za servis zaštite poverljivosti koriste se kriptografski mehanizmi -

tehnike skrivanja informacija pomoću neke transformacije na takav naĉin
da je samo odreĊena grupa korisnika moţe izvući u originalnom tekstu, a
svi drugi ne mogu. Ovlašćeni korisnici obezbeĊeni su sa istim kljuĉem
(simetriĉna kriptografija) ili drugim odnosnim kljuĉem iz para javnog i
privatnog kljuĉa (asimetriĉna kriptografija ili PKI-Public Key
Infrastructure), za izvlaĉenje originalne informacije iz šifrata.
Kriptografski mehanizmi koriste se u arhitekturi sistema zaštite za
implementaciju odreĊenih integralnih specifiĉnih servisa zaštite:
autentifikacije, poverljivosti, integriteta i neporecivosti informacija.

- 156 -
Skeneri sadrţaja i e-mail filteri mogu analizirati sadrţaj preuzetih
mobilnih kodova ili e-mail poruka za detekciju potencijalne povrede
sistema zaštite i izvršavanje akcije odgovora na pretnje. Skeneri sadrţaja
mogu detektovati ugraĊene slike u e-mail poruke, interpretirati tekst i
smestiti ih u karantin za dalju analizu. U ovom sluĉaju skeneri sadrţaja
direktno se koriste za zaštitu samih podataka.

- 157 -
4. KLJUĈNI TERMINI

Alati zaštite: hardversko-softverski mehanizmi i protokoli zaštite

(tehniĉke kontrole zaštite).
Autentifikacija: proces sa kojim korisnik (lice ili program) dokazuje
svoj identitet sistemu ili aplikaciji koji nude neki servis; standardni
mehanizmi za autentifikaciju su autentifikacioni protokoli i ureĎaji
(biometrijski, tokeni, smart kartice, ...); pošto većina korisnika u
organizacijama danas pristupaju sistemima i aplikacijama preko lokalne
mreţe ili udaljenom konekcijom, autentifikacija korisnika se smatra
mreţnim procesom.
Autorizacija: proces dodeljivanja legalnom korisnicima prava pristupa
objektima IS.
Autorizacioni serveri: pridruţuju skup privilegija ili prava pristupa
autentifikacionim entitetima (korisnici - ljudi, programi).
Detektori upada u raĉunarski sistem: IDS- Intrusion Detection
Systems, koriste se za prepoznavanje indikacija pokušaja upada,
upozorenje korisnika i korektivne akcije; koriste tehniku detekcije na
bazi potpisa i anomalija; dele se na HIDS (za RS) i NIDS (za RM).
EUA-Program za administraciju korisnika organizacije: (Enterprise
User Administration), univerzalno rešenje za kontrolu pristupa za
razliĉite platforme, koje moţe interaktivno raditi sa postojećim NOSSS
karakteristikama na većini platformi, a cilj je da centralizuje upravljanje
kontrolom pristupa u distribuiranom okruţenju.
Host-orijentisani alati: mehanizmi zaštite namenjeni za poboljšanje
zaštite operativnih sistema-OS hosta (raĉunarskog sistema -RS servera ili
radne stanice), aplikacija i podataka.
Kriptografski mehanizam: tehnika skrivanja informacija pomoću neke
transformacije na takav naĉin da je samo odreĊena grupa korisnika moţe
izvući u originalnom tekstu, a svi drugi ne mogu; za izvlaĉenje originalne
informacije iz šifrata ovlašćeni korisnici obezbeĊeni su sa istim kljuĉem
(simetriĉna kriptografija) ili drugim odnosnim kljuĉem iz para javnog i
privatnog kljuĉa (asimetriĉna kriptografija ili PKI-Public Key
Infrastructure).
Mehanizmi zaštite: pojedinaĉni, individualni algoritmi, ili metodi, ili
hardversko-softverski moduli za eliminisanje bezbednosnih problema u
mreţi; u logiĉkom smislu, mehanizmi predstavljaju naĉin realizacije
servisa zaštite.
NOSSS-Native Operation System Security Subsystem: podsistem zaštite
prirodnog OS, osnovni sloj zaštite OS u raĉunarskom sistemu; ukljuĉuje

- 158 -
osnovne mehanizme zaštite kao što su mehanizmi kontrole pristupa
datotekama i objektima RS, mehanizmi autentifikacije korisnika samom
OS i mehanizmi logovanja bezbednosno relevantnih dogaĎaja.
Preventivni detektori upada: IPS-Intrusion Prevention Systems,
omogućavaju, pored funkcija IDS, odreĊene vrste inteligentnih zamki za
napadaĉa (tipa ćupa meda-hony pot), kojima skreću njihovu paţnju i
izuĉavaju osobenosti u cilju preventivne zaštite od sledećeg napada.
Skeneri sadrţaja i e-mail filteri: analiziraju sadrţaj preuzetih mobilnih
kodova ili e-mail poruka za detekciju potencijalne povrede sistema
zaštite i vrše akcije odgovora na pretnje.
Skeneri sadrţaja: komplementarni su antivirusnim programima;
analiziraju sadrţaje poruka, e-pošte ili sadrţaje preuzete sa Interneta,
evaluiraju ih u odnosu na predefinisane politike zaštite, a zatim
izvršavaju neke akcije kada sadrţaj ne ispunjava zahteve politika zaštite.
Skeneri zaštite RS: rade na principu periodiĉnog monitorisanja aktuelne
konfiguracije platforme ĉija se ranjivost skenira i poreĊenjem ove
konfiguracije sa ţeljenom, odnosno predefinisanom osnovnom
konfiguracijom koja se smatra idealnom za datu platformu; u praksi
glavna je upotreba skenera ranjivosti zaštite samog OS.
Web filteri: mehanizmi mreţne zaštite koji se koriste za kontrolu
pristupa internih korisnika web lokacijama i selektivno blokiraju pristup
odreĊenim tipovima web lokacija, na bazi lokalne politike zaštite

- 159 -
5. LITERATURA

1. @stake, http://www.atstake.com, 2006.

2. Bace R., Mell P., Intrusion Detection Systems, NIST SP 800-31,
http://www.csrc.nist.gov/publications, 2006.
3. COAST - Computer Operations, Audit, and Security Technology, Pardu
univerzitet, SAD, http://www.cs.purdue.edu/coast/#archive , 2003.
4. http://www.cert.org/tech_tips/security_tools.html#D.
5. http://www.csrc.nist.gov/encription.
6. IDWG (Intrusion Detection Working Group),
http://www.ietf.org/html.charters/idwg-charter.html, 2005.
7. Purser S., A practical Guide to Managing Information Security,
Artech House, Boston-London, www.artechhouse.com, 2004.
8. RFC 1320 i RFC 1321, http://www.icann.rfceditorc.org.
9. Ruth A, Hudson K., Sertificat Security +, MicrosoftCo., CET
Beograd, 2004.
10. SANS Institute, Sans IDS FAQ,
http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm,
2006.
11. Scheiner Bruce, Applied Cryptography: Protocols Algorithms and
Source Code in Cryptography, 2nd edition, New York, John
Wiley and Sons, 1996.

- 160 -
9. TEHNOLOGIJE ZA ZAŠTITU RAĈUNARSKIH MREŢA

0. UVOD

Po završetku ovog poglavlja upoznaćete:

- osnovne razlike i sličnosti tehnologija zaštite RS i RM

- osnovne alate (mehanizme i protokole) za zaštitu RM
- infrastrukturne komponente zaštite RM (PKI, smart kartice)
- standarde, ograničenja i tehnologije zaštite bežičnih RM

Mreţna infrastruktura obuhvata kablovsku mreţu, ureĊaje za

povezivanje, matiĉne raĉunare i taĉke povezivanja sa mreţom. Mreţna
infrastruktura je kostur raĉunarske mreţe (RM). Uspešan napad na
mreţnu infrastrukturu moţe onesposobiti RM, ili izloţiti raznim vrstama
napada.

Za efektivnu zaštitu mreţne infrastrukture i RM treba poznavati tipove

potencijalnih napada, kao što su: fiziĉka sabotaţa, uništenje opreme;
njuškanje (eng. sniffing) paketa i prisluškivanje; analiza mreţnog
saobraćaja i skeniranje portova; rekonfigurisanje ili onemogućavanje
povezivanja, ili proboj ureĊaja mreţne zaštite; korupcija i upotreba
mreţnih ureĊaja za izvoĊenje napada na druge RM; ĉuvanje, ili širenje
neovlašćenih, ilegalnih, ili destruktivnih servisa na mreţnim ureĊajima i
brisanje podataka.

Od većine potencijalnih napada na mreţnu infrastrukturu i RM osnovna

zaštita je kontrola pristupa kritiĉnim resursima, protokolima i pristupnim
taĉkama, ukljuĉujući fiziĉku zaštitu i zaštitu konfiguracija ureĊaja. Drugi
aspekt zaštite RM je neprekidni nadzor mreţnog saobraćaja (mreţni
skeneri saobraćaja), zaštita servera, mobilnih ureĊaja, radnih stanica i
ureĊaja za umreţavanje, detekcija upada u RM (NIDS), zaštita udaljenog
pristupa (RADIUS, TACAS protokoli) i zaštita beţiĉno povezanih
lokalnih mreţa (WLAN-Wireless LAN).

Infrastruktura sa javnim kljuĉem (PKI-Public Key Infrastructure),

poznata i kao asimetriĉna kriptografija, jedna je od najbitnijih
komponenti zaštite savremenih RM i obezbeĊuje brojne prednosti u
odnosu na simetriĉne kriptografske sisteme u savremenim poslovnim
IKT sistemima. Za visoku bezbednost IKT sistema, u kombinaciji sa PKI

- 161 -
sistemom u prvom redu koriste se autentifikacioni i autorizacioni serveri
i smart kartice, tokeni i kriptografski moduli za zaštitu kriptografskih
tajni.

Svi tipovi beţiĉnih mreţa (WLAN) inherentno su nebezbedni - koriste

radio frekvencije za prenos informacija, što lako moţe kompromitovati
informacije na prenosnom putu. WLAN, klasiĉan Ethernet LAN bez
kablovske infrastrukture, sa velikom uštedom komunikacione
infrastrukture i lakoćom implementacije, ima najveću praktiĉnu primenu.
Beţiĉna tehnologija je izgraĊena na bazi IEEE 802.11b standarda u SAD
i GSM (Groupe Spécial Mobile) standarda u EU. WEP (Wireless
Equivalent Protocol) protokol za zaštitu prenosa, koji je dizajniran da
obezbedi iste karakteristike zaštite kao i kod prenosa fiziĉkim putevima:
raspoloživost, poverljivost i integritet informacija, pokazao je brojne
slabosti.

Treća (3-G) generacija tehnologije beţiĉnih sistema koriguje sve uoĉene

bezbednosne ranjivosti navedenih standarda WEP protokola za zaštitu
prenosa. 3-G tehnologija usmerena je na poboljšanje komunikacije
podataka i glasa beţiĉnim putem, koristeći bilo koji od raspoloţivih
standarda.

- 162 -
1. MREŢNA AUTENTIFIKACIJA I AUTORIZACIJA

1.1. Autentifikacioni protokoli

Glavni bezbednosni problem postojećih TCP/IP mreţa je lakoća

sa kojom se podaci presresti i analizirati. Ovaj problem odnosi se na
TCP/IP protokol i naĉin na koji rade noseći mreţni protokoli. Zato svaki
mehanizam autentifikacije koji se oslanja na pasvorde u otvorenom
tekstu ili bilo koja predvidljiva razmena podataka nije bezbedna u
mreţnom okruţenju.

Zaštita mreţne infrastrukture deo je rešenja ovog problema, ali ne

obuhvata mogućnost da neovlašćeni korisnik moţe koristiti svoju opremu
za pristup mreţi i aktivirati snifer ili sliĉan alat za kontrolu saobraćaja u
mreţi. Na isti naĉin ne moţemo u beţiĉnim (WLAN) mreţama [20], ili
na Internetu verovati u mehanizme zaštite drugih korisnika za koje oni
misle da su odgovarajući. Zato je neophodno ugraditi mehanizme zaštite
u sam proces razmene podataka. Uobiĉajen naĉin da se ovo uradi je
korišćenje standardnih autentifikacionih protokola. Treba uoĉiti da
autentifikacija nije isto što i uspostavljanje bezbedne sesije i da svaka
konekcija koja ne koristi dodatne mere zaštite, kao što su šifrovanje ili
mehanizmi za zaštitu integriteta, moţe biti kompromitovana.

U najjednostavnijem sluĉaju autentifikacija korisnika ukljuĉuje unošenje

pasvorda preko uspostavljene bezbedne sesije, kao što je SSL (Secure
Socket Layer) protokol. Ovaj metod autentifikacije korisnika ĉesto se
koristi za pristup web aplikacijama na Internetu. Iako SSL nije stvarni
primer autentifikacionog protokola, osnovni je protokol koji se koristi za
zaštitu pasvorda u toku prenosa, [18].

Većina autentifikacionih protokola zasniva se na konceptu „upit-

odgovor― protokola. Osnovna ideja je da sistem zahteva dokaz o
identitetu, a korisnici inicijalno koriste neki drugi mehanizam za razmenu
kriptografskih kljuĉeva. Kada korisnik ţeli da dobije pristup, on se
identifikuje sistemu, koji odgovara sa sluĉajnim upitom (chalange).
Korisnik šifruje ovaj upit koristeći svoj tajni kljuĉ i šalje nazad sistemu,
koji koristi matematiĉki par istog kljuĉa (javni kljuĉ korisnika) za
dešifrovanje originalne informacije. Ovo je zaista dokaz o identitetu, pod
pretpostavkom da je korisnik jedina osoba koja poseduje tajni kljuĉ,
neophodan za šifrovanje sluĉajnog upita sistema. Ako upit nije sluĉajna

- 163 -
vrednost, zlonamerni korisnik ga moţe presresti, laţno se predstaviti i
izdati novu vrednost upita korisniku, primiti transformisani odgovor i
obezbediti pristup ciljnom sistemu.

Autentifikacioni protokoli su oblast za sebe, a protokoli zaštite su

priliĉno kompleksni i teški za podele i klasifikacije. Primer
kompleksnosti autentifikacionih protokola je Needham – Schroeder
protokol koji se koristi u Kerberos sistemu (Windows NT 4.0 OS) i ima
ranjivost koja omogućava napadaĉu pristup korišćenjem starog kljuĉa.
Autentifikacioni ureĊaji koriste se u procesu autentifikacije, a obezbeĊuju
korisniku neki fiziĉki objekt (identifikator) koji se zahteva za uspešno
kompletiranje procesa autentifikacije. Do sada većina ureĊaja za
autentifikaciju spada u sledeće kategorije: smart kartice (opisane u
sekciji 1.7.2.), biometrijske ureĎaje i tokene.

- 164 -
1.2. Serveri za autentifikaciju i autorizaciju

Autentifikacioni serveri se koriste za centralizaciju upravljanja

procesom autentifikacije u RM. Autorizacioni serveri idu korak dalje
pridruţujući skup privilegija ili prava pristupa autentifikacionih entiteta
(korisnika - ljudi, programa). Iako A&A serveri nisu nuţno obavezni u
sistemima za kontrolu pristupa sa udaljenih mreţnih lokacija, oni se
uobiĉajeno koriste za ovaj servis. Na primer, u Windows OS primarni
kontroler domena (PDC) efektivno radi kao autentifikacioni server za
Win klijente u lokalnoj mreţi.

Serveri za A&A obezbeĊuju odgovarajuće servise za više klijenata u

klijent-server arhitekturi. Mogu obezbediti sve apstraktne slojeve
programa, sve dok su klijenti opremljeni sa odgovarajućim interfejsom i
korektno konfigurisani. Neki serveri mogu izvršavati funkcije
dodeljivanja uloga korisnicima (CISCO A&A serveri), [23].

Tipiĉan primer kako A&A serveri rade ukljuĉuje udaljenog korisnika,

koji bira broj servera organizacije preko PSTN (javne telefonske) mreţe.
UreĊaj poznat kao server mrežnog pristupa-NAS (Network Access
Server) prima vezu od PSTN i nakon verifikacije identiteta korisnika i
primene neke restrikcije, dopušta konekciju na zahtevani interni host. Za
ove funkcije NAS moţe koristiti lokalnu bazu podataka ili što je ĉešće,
moţe koristiti servise namenjenog A&A servera.

U serverskoj konfiguraciji NAS igra ulogu posrednika izmeĊu korisnika i

servera prenoseći svaki zahtev za informacijama od servera prema
klijentu i vraćajući odgovor serveru. Kada server ima dovoljno
informacija da prihvati/odbije zahtev klijenta, tada šalje odgovor NAS-u,
koji izvršava odluku prihvatanjem/odbijanjem konekcije prema skupu
predefinisanih pravila.

Metod autentifikacije i upravljanje pravima pristupa kontroliše lokalna

organizacija, koja moţe koristiti razne tehnologije kao što su pasvordi,
tokeni, ili smart kartice.

Fleksibilnost za podršku razliĉitih metoda A&A postiţe se

implementacijom standardnog protokola na nivou aplikacija izmeĊu NAS
i bezbednosnog servera. Ovi se protokoli dizajnirani da podrţe generiĉku

- 165 -
razmenu izmeĊu NAS i servera koji ne zavisi od procesa A&A. Postoje
dva glavna protokola koji se danas koriste, [26], [ 4]:

- RADIUS (Remote Authentication Dial In User Service) protokol

i
- TACACS + (Terminal Access Controller Access Control Service)
protokol.

Osim razlika u minornim detaljima ova su dva protokola vrlo sliĉnih

funkcionalnosti. Osnovne razlike su:

- RADIUS se izvršava preko protokola korisniĉkih datagrama

(UDP-User Datagram Protocol), dok se TACACS+ izvršava
preko TCP protokola.
- RADIUS pruţa korisniĉki profil sa proverom autentiĉnosti koja
definiše sve specifiĉne parametre tog korisnika, dok TACACS+
razdvaja provere autentifikacije i autorizacije.
- TACACS+ se uglavnom koristi samo za mreţne ureĊaje kao što
su ruteri i komutatori, a RADIUS koriste raĉunari i drugi mreţni
ureĊaji.

A&A
server

3.Zahtev za 4. Odgovor A&A

autentifikaciju servera
NAS

2. Zahtev RADIUSa
1. Zahtev korisnika
RADIUS
Server

PSTN 5. Odgovor RADIUSa

6. Pristup ciljnom
hostu
Ciljni
host

Sl. 1.1. Funkcionalni model RADIUS protokola

Na slici Sl. 1.1. prikazan je funkcionalni model RADIUS protokola,

kojeg koriste neki NAS da omoguće udaljeni pristup korisnika.

- 166 -
Sekvence aktivnosti su sledeće:

1. Korisnik inicira dial-up vezu sa NAS serverom. NAS traţi

korisniĉko ime i pasvord, koje korisnik dostavlja NAS-u sa
zahtevom.
2. NAS radi kao RADIUS klijent i šalje poruku zahteva za pristup
RADIUS serveru.
3. RADIUS server prenosi autentifikacione podatke na A&A server,
što moţe ukljuĉivati i korišćenje sopstvenog (autorskog)
protokola.
4. Server za A&A dopušta/odbija zahtev.
5. RADIUS server odgovara NAS-u sa porukom o
prihvatanju/odbijanju pristupa, zavisno od rezultata
autentifikacije.
6. Ako je autentifikacija uspešna, NAS server dopušta pristup
ciljnom hostu.

Korišćenje servera za A&A znaĉajno povećava bezbednost pristupa

udaljenih korisnika, ali stvarni nivo bezbednosti dostiţe se u zavisnosti
od primenjenog metoda A&A. Tako pasvord mehanizam ne obezbeĊuje
visoku bezbednost, dok kriptografski mehanizam upit-odgovor tipa
predstavlja znaĉajnu barijeru za napadaĉa. Izbor zavisi od procene rizika.
MeĊutim, ĉak i sa visoko bezbednom implementacijom, tehnika A&A ne
štite podatke koji se izmenjuju izmeĊu korisnika i internog sistema
(hosta) kada se konekcija jednom uspostavi. Zato treba ići korak dalje i
implementirati zaštitni protokol izmeĊu krajnjeg korisnika i
odgovarajućeg terminala iza NAS. Ovo rešenje štiti poverljivost podataka
i integritet same sesije.

Za web aplikacije sa zahtevom za visoki stepen skalabilnosti razvijen je

EAM (Extranet Access Management) programski paket koji obezbeĊuje
servise A&A u ekstranet okruţenju (što je suprotno udaljenom pristupu).

- 167 -
1.3. Integritet raĉunarske mreţe

1.3.1. Skeneri zaštite računarske mreže

Skeneri zaštite RM po konceptu sliĉni su skenerima zaštite RS, s

tim sa otkrivaju ranjivosti RM. Najjednostavniji skener ranjivosti RM
samo mapira ureĊaje povezane u RM, koristeći jednostavni probni signal
kao što je eho ICMP (Internet Control Message Protocol), poznat kao
ping (pingovanje). Na višem nivou su jednostavni alati koji mogu
mapirati portove, pingujući individualne TCP ili UDP portove na
detektovanim hostovima. Ovi alati mogu mapirati mreţu i identifikovati
koji su mreţni servisi operativni. Komercijalni alati, iako koriste manje
više iste tehnike znatno su moćniji jer sadrţe baze podataka sa poznatim
ranjivostima. Mreţni skeneri bazirani su na sliĉnim principima kao i host
orijentisani skeneri, tj. uporeĊuju aktuelnu konfiguraciju RM i hostova sa
predefinisanom referentnom konfiguracijom i izveštavaju o otkrivenim
razlikama. Generalno, mreţni skeneri obezbeĊuju više vrsta informacija,
ali sa manje detalja od skenera raĉunarskih sistema.

Skeneri ranjivosti RM imaju tipiĉnu arhitektura koja obuhvata:

- modul za skeniranje,
- bazu podataka sa poznatim ranjivostima (definicijama mreţnih
napada),
- modul za generisanje i prezentaciju izveštaja i
- korisniĉki interfejs.

Tipiĉno modul za skeniranje radi prema zadacima iz politike zaštite, koja

omogućava administratoru da prilagoĊava proces skeniranja konkretnim
zahtevima okruţenja. Modul za skeniranje proverava RM na ranjivosti,
uporeĊivanjem sa poznatim ranjivostima iz baze podataka i
identifikovanjem (prepoznate) tekuće ranjivosti i daje podatke na izlazu.
Konaĉni rezultati izveštavaju se preko korisniĉkog interfejsa za
izveštavanje. Ovaj proces prikazan je na slici Sl. 1.2.

- 168 -
 Baza
Modul za podataka
skeniranje

Skeniranje na bazi
politike zaštite

Generator
izveštaja

Komande i
izveštaji

Korisnički
interfejs

Sl. 1.2. Skeneri ranjivosti raĉunarskih mreţa

Efektivnost skenera RM zavisi od sliĉnih faktora kao i host orijentisani

skeneri.:

- aţurnosti baza podataka poznatih ranjivosti,

- lokacije skenera u topologiji RM, u odnosu na ureĊaje koji mogu
blokirati mreţni saobraćaj (firewalls, rutere,..), što se mora
paţljivo planirati,
- adekvatnosti politike skeniranja i
- efikasnosti procesa korekcije koji sledi po otkrivanju ranjivosti.

Poslednji faktor je najvaţniji, jer bez otklanjanja ranjivosti proces

skeniranja nije završen.

1.3.2. Skeneri telefonskih veza

Skeneri telefonskih veza predstavljaju komercijalni razvoj

hakerskih alata tzv. war dialing programa koji se koriste za
identifikovanje potencijalnih ranjivosti sistema preko telefonske linije.
Telefonski skeneri su konceptualno sasvim sliĉni skenerima ranjivosti
RM. Oni biraju seriju telefonskih brojeva i vrše odreĊeni broj
bezbednosnih provera i izveštavaju o rezultatima. Telefonski skeneri na
taj naĉin konstruišu bezbednosnu mapu telefonskog sistema organizacije,
dok skeneri ranjivosti RM konstruišu mapu LAN ureĊaja korišćenjem
mapiranjem IP adresa.
Telefonski skeneri detektuju ranjive puteve u RM organizacije koji su
pristupaĉni sa javne telefonske mreţe (PSTN). Posebno oni detektuju
neovlašćene i nepoznate modeme prisutne na LAN-u i koji mogu

- 169 -
prihvatiti dolazne pozive. Principi rada telefonskih skenera zasnivaju se
na kombinaciji tehnika probe (pingovanja) i prepoznavanja zahteva za
izveštavanje (prompts) o ranjivostima na nivou OS (npr., UNIX sistem sa
slabim pasvordom) i na nivou aplikacija (npr., udaljeni pristup sistemu
bez pasvorda).

Pošto se kontrola modema ĉesto vrši kroz proceduralna rešenja (mada

postoje programi za automatsku detekciju modema), telefonski skeneri
znaĉajno povećavaju stopu detekcije neovlašćenih modema
automatizacijom procesa detekcije.

Postojeći komercijalni programi veoma su sofisticirani i poseduju ĉitav

spektar opcija konfiguracije, koje omogućavaju operatoru da prilagodi
skeniranje specifiĉnim zahtevima. Posebno je znaĉajna fleksibilnost koja
obezbeĊuje specifikaciju brojeva koje treba skenirati, sa mogućnošću
unošenja pojedinaĉnih ili grupnih brojeva za skeniranje. Skeneri se mogu
programirati za rad u odreĊeno vreme dana, predefinisati sa logiĉkim
ograniĉenjima samog procesa skeniranja (zaustavljanje ponovnog biranja
posle odreĊenog broja pokušaja korišćenja sekvencijalnog ili sluĉajnog
biranja i definisanje perioda izmeĊu dva biranja).

OdreĊeni alati podrţavaju razliĉite modove rada dopuštajući operateru da

bira izmeĊu pasivne identifikacije RS koji odgovara na poziv ili
agresivnijeg pokušaja proboja. Poslednji naĉin rada ukljuĉuje pokušaj
pogaĊanja kombinacije korisniĉkog imena/pasvorda i razvoj
kompleksnog scenarija proboja kojeg odreĊuje tip detektovanog
programa.

Postoje rešenja za distribuirano skeniranje udaljenom instalacijom biraĉa

pod kontrolom centralne upravljaĉke stanice, kao i šifrovane
komunikacije izmeĊu centralne i udaljenih distribuiranih komponenti.
Ovo omogućava paralelno skeniranje.

U većini sluĉajeva telefonski skeneri poseduju jednostavan GUI

(Graphic User Interface) i proizvode nekoliko razliĉitih tipova izveštaja
kao i mogućnost prilagoĊavanje tipa izveštaja korisniku (kastomizacije).

- 170 -
1.4. Kontrola pristupa raĉunarskoj mreţi

1.4.1. Mrežne barijere (Firewalls)

Mreţne barijere (Firewalls) su ureĊaji ili konstrukcije ureĊaja

koje nameću politiku kontrole pristupa izmeĊu dve ili više segmenata
RM. Termin barijera uvek treba smatrati skupom ureĊaja, što je
kompatibilno sa idejom da je to arhitekturno rešenje koje obezbeĊuje
mreţnu zaštitu po dubini. MeĊutim, komercijalni termin barijere odnosi
se uvek na pojedinaĉni proizvod, [7].

Barijere dopuštaju ili odbijaju konekcije od jedne prema drugoj RM, na

bazi skupa pravila postavljenih na niskom nivou koja se mogu izraziti
kao protokoli podataka. Ovi podaci se uzimaju sa nivoa 3-7 OSI modela.
U TCP (IP) okruţenju normalno se koriste slojevi 5, 6 i 7, pošto su deo
aplikacija, tako da se pravila barijera za dopuštanje ili odbijanje pristupa
baziraju na mreţnom, transportnom i aplikativnom sloju. Barijere
generalno rade sa saobraćajem na aplikativnom nivou, ne prepoznaju
protokole koji nisu TCP/IP pa moraju biti specifiĉno konfigurisane da
prepoznaju druge tipove protokola. Oĉigledno, barijere imaju vrlo
ograniĉeni skup podataka sa kojima mogu raditi, što ograniĉava i realne
rezultate zaštite sa barijerama.

Većina savremenih komercijalnih proizvoda ukljuĉuje funkcionalnost za

autentifikaciju korisnika, koji je glavni korak napred u razvoju barijera,
pošto omogućava da se mreţna konekcija povezuje sa licem, a ne sa
mreţnom adresom (IP). Postoje dve znaĉajne klase komercijalnih
programskih proizvoda barijera koje rade na razliĉitim principima, ali
postiţu sliĉne rezultate:

1. Barijere koje rade na principu potpune kontrole „stanja―

konekcije i filtriranja rutiranih IP paketa od jednog mreţnog
interfejsa do drugog. Mehanizmi za potpunu kontrolu stanja
konekcija i filtriranje izgraĊeni su na principu jednostavnih
tehnika filtriranja. Programske barijere presreću već rutirane
pakete na mreţnom sloju i analiziraju informacije o protokolu od
slojeva 3 – 7, zajedno sa informacijom koja opisuje „stanje―
konekcije da bi se odredilo da li pakete treba zaustaviti ili
propustiti. Za protokole bez korekcije, kao što su UDP, ovo se
postiţe korišćenjem koncepta virtuelne sesije, u kojem je

- 171 -
 informacija o stanju uskladištena pomoću programske barijere,
ĉak iako je sam protokol bez informacija o stanju konekcije.
2. Barijere na aplikativnom sloju poznate kao aplikativna mreţna
kapija (gateway) ili proksi barijere, koje ne rutiraju direktno
pakete. Dolazni paketi se procesiraju komunikacionim
programom i prenose specijalizovanoj aplikaciji koja moţe da
razmatra odreĊeni protokol koji se koristi na visokom nivou
apstrakcije. Pošto nameću kontrole na aplikativnom sloju, proksi
barijere su specifiĉne za aplikacije, što znaĉi da svaki put kada se
razvija novi protokol, zahteva se novi proksi za zaštitu. U
stvarnosti, većina savremenih protokola nemaju proksi barijere
koje ih prate, a proksi serveri se uglavnom koriste za kontrolu
standardnih Internet protokola na bazi zahteva za komentar
(RFC), kao što su FTP ili HTTP. Naĉini rada filterskih barijera i
aplikativnih-gateway barijera prikazani su na slici Sl. 1.3.
Sve ĉešće proizvoĊaĉi kombinuju karakteristike obe barijere.

Principi rada filterskih i aplikativnih barijera

Filterske barijere Aplikativne barijetre
OSI Paketi se ispituju Paketi se ne
slojevi posle rutiranja rutiraju

7 aplikativni

6 prezentacioni

5 sesijski

4 transportni H4 H4

3 RM H3 H4 H3 H4 H3 H4 H3 H4

2 H2 H3 H4 H2 H3 H4 H2 H3 H4 H2 H3 H4

1 fizički

Izlaz Ulaz Izlaz

Ulaz
21.11.2006 21

Sl. 1.3. Principi rada filterskih i aplikativnih barijera

- 172 -
1.4.2. Proksi serveri

Proksi serveri funkcionišu sliĉno aplikativnim gateway

barijerama. Dok su barijere namenjene za kontrolu mreţnog pristupa
dolaznog i odlaznog saobraćaja, proksi serveri su usmereni na kontrolu
konekcija koje dolaze iz interne RM. Proksi serveri zahtevaju
autentifikaciju krajnjeg korisnika, vrše restrikciju komunikacija na
definisani skup protokola, primenjuju restrikciju kontrola pristupa i
loguju kontrolne tragove.

Najĉešći tip proksi servera u praksi su web proksi serveri, koji se ne

koriste samo za zaštitu. Na primer, jedna od najvaţnijih funkcija web
proksi servera je keširanje (skladištenje u keš memoriju) podataka za
poboljšanje performansi. Striktno govoreći, proksi serveri nisu
mehanizmi za zaštitu RM i korektnije ih je smatrati višefunkcionalnim
mehanizmima, koji implementiraju vaţnu bezbednosnu funkcionalnost.

1.4.3. Web filteri

Web filteri se koriste za kontrolu pristupa internih korisnika web

lokacijama. Ovi mehanizmi mreţne zaštite omogućavaju administratoru
da selektivno blokira pristup odreĊenim tipovima web lokacija, na bazi
lokalne politike zaštite.

Web filteri dopuštaju ili blokiraju pristup spoljnim web lokacijama na

bazi lokalno definisane politike i koriste se i za kontrolu produktivnosti
zaposlenih i za povećanje bezbednosti web lokacije. Web filteri
kontrolišu rizik sa Interneta, spreĉavajući korisnike da pristupaju
lokacijama koje poseduju neodgovarajući sadrţaj ili maliciozne kodove.

Odluka o blokiranju/dopuštanju odreĊenog zahteva donosi se na bazi

konsultovanja instalirane baze podataka o potencijalno problematiĉnim
web lokacijama, koje odrţavaju i regularno aţuriraju proizvoĊaĉi
(prodavci), sliĉno aţuriranju antivirusnih programa. Neki proizvodi
poseduju agente koji analiziraju koje sve web lokacije zaposleni posećuju
i aţuriraju baze podataka To omogućava da organizacija kastomizuje
(prilagodi korisniku) svoje posebne zahteve. Ovi mehanizmi tipiĉno
ukljuĉuju: mogućnost blokiranja odreĊenih kategorija sadrţaja sa web
lokacija; primenu restrikcija za odreĊeni period dana; definisanje naĉina

- 173 -
monitorisanja pokušaja pristupa; izdavanje standardnih i kastomizovanih
izveštaja i praćenje ponašanja korisnika i poseta odreĊenim lokacijama.

1.5. Monitoring mreţne zaštite

1.5.1. Mrežni sistemi za detekciju upada

Mreţni sistemi za detekciju upada (NIDS-Network Intrusion

Detection Systems) u većini sluĉajeva rade na 2. sloju OSI modela.
Programska rešenja stavljaju mreţnu interfejs karticu (NIC) u
promiskuitetni reţim rada, privilegovanu operaciju na većini sistema,
koja daje pristup mreţnom saobraćaju u realnom vremenu. Na isti naĉin
rade i analizatori mreţe i programi za njuškanje (sniferi). NIDS sistemi
su komplementarni HIDS sistemima po mogućnosti prijema i analize
informacija, ali o protokolima koje nisu na raspolaganju host sistemu.
Pošto rade na mreţnom sloju, detektuju sisteme nezavisno od OS i
omogućavaju zaštitu velikog opsega krajnjih platformi. Mogućnosti
aplikacije NIDS sistema u RM prikazana je na Sl. 1.4, [27].

Sl. 1.4. Mogućnosti primene NIDS sistema u RM

Zbog sliĉnosti naĉina rada, NIDS programi takoĊe imaju nekoliko

zajedniĉkih ograniĉenja sa tehnologijama barijera. Barijera treba da
razume i prepozna protokol da bi donela odluku o pristupu na bazi
informacija koje sadrţi, a NIDS program ne moţe detektovati anomalije
protokola bez takvog razumevanje. Oĉigledno, ni barijere ni NIDS
sistemi ne mogu interpretirati podatke i bilo koja arhitektura zaštite koja
kombinuje barijere, šifrovanja u RM i NIDS programe treba da uzme u
obzir ovo ograniĉenje.

- 174 -
NIDS program moţe igrati vaţnu ulogu u upravljanju malicioznim
kodovima, tako što se moţe konfigurisati da prepozna odreĊene potpise i
preduzeti neke predefinisane akcije, posebno u periodu izmeĊu
inicijalnog napada i raspoloţivosti prve definicije malicioznog kôda.
NIDS program takoĊe moţe biti konfigurisan da spreĉava prolaz
inficiranih objekata izvan organizacije, što je koristan mehanizam za
spreĉavanje širenja malicioznih programa na druge hostove izvan
organizacije. Odgovor NIDS sistema moţe biti identifikacija i
registrovanje dogaĊaja, neka aktivna protivmera ili kombinacija ove dve.

Pasivna tehnika upozoravanja ukljuĉuje izveštavanje o problemu na

ekranu monitora, generišući SNMP (Simple Network Management
Protocol) alarme, aktivirajući pejdţere, mobilne telefone ili sliĉne
ureĊaje.

Aktivne zaštitne protivmere treba implementirati sa ekstremnom

paţnjom, pošto mogu izazvati prekid servisa posebno u sluĉaju laţnih
pozitiva, jer ukidaju konekcije u interakciji sa programom barijera.

U PRILOGU I 9A date su blok šeme strategija centralizovanog i

distribuiranog upravljanja NIDS. U cilju razumevanja mogućnosti izbora
lokacije NIDS u RM i prednosti svakog rešenja, razvijena je Vežba GI
P9A sa zadatkom da studenti primene steĉeno znanje o izboru lokacije
NIDS u RM kroz praktiĉni rad i diskusiju.

- 175 -
1.6. Poverljivost i integritet mreţnih podataka

1.6.1. Kriptografski mehanizmi i protokoli

Kriptografski mehanizmi i protokoli imaju najznaĉajniju primenu

za zaštitu podataka na prenosnom putu kroz RM. Koncept AC kako se
primenjuje u RS, u toj formi ne postoji u RM. Za kontrolu pristupa
izmeĊu dve RM mogu se koristiti tehnike kao što su filtriranje paketa u
TCP/IP okruţenju i uspostavljanje zatvorenih grupa korisnika u X.25
okruţenju, ali ni jedna od ove dve tehnike ne moţe se koristiti za zaštitu
podataka koji putuju fiziĉkim vezama.

Za zaštitu podataka koji putuju kroz potencijalno ne-prijateljske mreţe,

koriste se specifiĉno dizajnirani zaštitni protokoli, koji implementiraju i
izvršavaju jedan ili više sledećih mreţnih servisa zaštite: autentifikacije,
zaštite poverljivosti, zaštite integriteta i neporecivosti.

Protokoli za autentifikaciju više su vezani za korisnike i ureĊaje nego za

podatke, iako se i digitalni potpis (DS) i MAC (Message Authentication
Codes) mogu koristiti za autentifikaciju izvora podataka koje štite. Dok
se DS bazira na PKI i asimetriĉnoj kriptografiji, MAC se zasniva na
simetriĉnom algoritmu, što sa aspekta autentifikacije nije bitno, ali je
vaţno u kontekstu servisa neporecivosti.

Zaštita poverljivosti mrežnih podataka postiţe se korišćenjem

kriptografskih alata. Standardni pristup je korišćenje PKI kriptografije za
razmenu simetriĉnog kljuĉa i korišćenje simetriĉnog kljuĉa za šifrovanje
u toku sesije masovnog šifrovanja podataka. Zbog ovog simetriĉni kljuĉ
se ĉesto naziva sesijski kljuĉ. Postoje dve osnovne tehnike za
sporazumevanje o sesijskom kljuĉu:

1. korišćenje protokola za uspostavljanje kljuĉa, npr., Diffie –

Hellman, [18], ili
2. generisanje simetriĉnog kljuĉa i transfer asimetriĉnim sistemom,
šifrovanjem sa javnim kljuĉem udaljenog korisnika.

Ovo kombinuje prednosti asimetriĉnih i simetriĉnih algoritama

korišćenjem asimetriĉnih algoritama za jednostavniju distribuciju kljuĉa i
simetriĉnih algoritama za šifrovanje. Za zaštitu komunikacije dve
poverljive RM u nepoverljivom Internet okruţenju koriste se VPN

- 176 -
(Virtual Private Network). VPN konekcije su šifrovane (IPsec), [9] i
mogu se koristiti na privatnim i javnim mreţama. Dva VPN servera, ili
VPN klijent i VPN server mogu da naprave VPN konekcije. Da bi
realizovali meĊusobnu bezbednu šifrovanu vezu dva ureĊaja koriste
dogovoreni metod šifrovanja. Ako VPN implementiraju dva servera,
šifruju komunikaciju izmeĊu dve taĉke.

Zaštita integriteta u mrežnom okruženju komplikuje se ĉinjenicom da se

moraju razmatrati dva tipa integriteta: integritet podataka i integritet
sesije komunikacije.

Koncept integriteta podataka lako je razumljiv – treba obezbediti da

podaci stignu na odredište u istoj formi u kojoj su poslati (da nisu ni u
kom vidu modifikovani). Protokoli štite integritet podataka koristeći
tehnike bezbednog heširanja (eng. hash ili message digest-MD). Heš je
jednosmerna matematiĉka funkcija koja se lako raĉuna u jednom smeru a
praktiĉno (teško) je nerešiva u inverznom smeru. Heš stvara vrednost
fiksne veliĉine podataka na osnovu jedinice podataka promenljive
veliĉine. Algoritam heširanja daje istu heš vrednost na osnovu istih
ulaznih podataka, odnosno, dve razliĉite ulazne veliĉine nikada nemaju
istu heš vrednost. Heš podaci se mogu porediti sa otiskom prsta neke
osobe. Otisak prsta je jedinstven za tu osobu i relativno fiksne veliĉine,
ali ni pribliţno nije velik kao ta osoba. Heš je jedinstven identifikator
kojeg je praktiĉno nemoguće dobiti sa drugaĉijim ulaznim podacima, a
deo je svih podataka koje predstavlja. Uobiĉajeni heš algoritmi koji se
najviše koriste su: MD4, MD5 i SHA-1:

- MD4, izraĉunava 128-bitni heš poruke, vrlo brz, srednje snage,

[24],
- MD5, 128-bitni heš poruke, brz, bezbedniji od MD4, široko
primenjen, [24],
- SHA-1 (Secure Hash Algorithm), izraĉunava 160-bitni heš,
sporiji od MD5, standardan u federalnom IS vlade SAD, [17], i
- SHA-256, SHA-384 i SHA-512, heš algoritmi u razvoju su,
[13].

Pošiljalac poruke pravi heš poruke sa odreĊenim kljuĉem, koja se naziva

kôd za proveru autentiĉnosti poruke (MAC-Massage Authentication
Code), a primalac verifikuje heš vrednost sa istim kljuĉem. Ako se
dobije ista vrednost heša, poruka je nepromenjena.

- 177 -
Integritet sesije namenjen je da obezbedi da karakteristike
komunikacione sesije nisu modifikovane ni na koji naĉin. Tehnike
obezbeĊenja integriteta sesije obiĉno su zasnovane na ukljuĉivanju
brojeva sekvenci ili vremenskog peĉata u zaštićenoj poruci. Koriste se
asimetriĉni algoritmi u kombinaciji sa heš funkcijama i digitalnim
potpisom (DS). DS pravi se stvaranjem heša teksta poruke i šifrovanjem
hešovane vrednosti privatnim kljuĉem na strani pošiljaoca. Primalac
poruke dešifruje šifrovanu heš vrednost sa javnim kljuĉem pošiljaoca i
verifikuje heš vrednost. Ako se dobije ista vrednost heša, sesija je
nepromenjena.

Servis neporicanja najmanje je intuitivan od svih ostalih i namenjen je za

zaštitu uĉesnika u razmeni od kasnijeg poricanja akcija koje su izvršili u
toku razmene. Mnogo je teţe spreĉiti primaoca poruke da porekne prijem
poruke nego pošiljaoca da porekne da je poruku poslao.

Da bi dokazao da je pošiljalac poslao odreĊenu poruku, primalac mora

zahtevati da pošiljalac sistematski digitalno potpisuje poruke pre slanja.
Ako pošiljalac kasnije pokuša da porekne slanje poruke, primalac
jednostavno proizvede i verifikuje digitalno potpisanu poruku kao
neporeciv dokaz da je pošiljalac zaista poslao odreĊenu poruku.

Ako pošiljalac ţeli dokaz da je primalac primio odreĊenu poruku mora

zahtevati da primalac sistematski generiše potvrde o prijemu za svaku
poslatu poruku i da je digitalno potpisuje. Ako primalac kasnije pokuša
poreći da je primio poruku, pošiljalac proizvede i verifikuje digitalno
potpisanu potvrdu o prijemu. Treba zapaziti da je ovde bitno razlikovati
ĉitanje poruke od prijema poruke.

Primeri protokola koji implementiraju mreţne servise zaštite ukljuĉuju:

SSL (Secure Socket Layer) i TLS (Transport Layer Security) protokole,
koji su najtraţeniji protokoli mreţne zaštite u web okruţenju i IPsec
protokol, koji je najpoţeljniji za implementaciju VPN (Virtual Private
Network) servisa, koji povezuje dve poverljive mreţe kroz nepoverljivi
Internet.

- 178 -
1.7. Infrastrukturna komponenta mreţne zaštite

1.7.1. Infrastruktura sa javnim ključem (PKI)

Infrastruktura sa javnim kljuĉem (PKI-Public Key Infrastructure),

poznata i kao asimetriĉna kriptografija, jedna je od najbitnijih
komponenti zaštite savremenih RM iz više razloga, [29]:

- lakše obuhvataju veći broj korisnika od simetriĉne kriptografije,

jer svaki korisnik zahteva samo 1 par kriptografskih kljuĉeva za
komunikaciju sa svim ostalim, za razliku od simetriĉne
kriptografije gde jedan korisnik deli isti kljuĉ sa svakim
pojedinaĉnim korisnikom u vezi;
- PKI delimiĉno rešava problem distribucije kljuĉa kod simetriĉne
kriptografije i
- PKI obezbeĊuje okvir za protokole zaštite transakcija i
implementaciju servisa DS, zaštite integriteta i neporicanja
aktivnosti, pridruţujući jedinstveni privatni kljuĉ svakom
uĉesniku.

Glavni nedostatak PKI sistema je poverenje korisnika u povezanost

javnog kljuĉa i nominalnog vlasnika. Da bi se iskoristile sve prednosti
PKI sistema, korisnici moraju verovati u legalnu povezanost izmeĊu
uĉesnika i njegovog javnog kljuĉa. Iako se javni kljuĉ ne mora ĉuvati u
tajnosti kao simetriĉni kljuĉ, teško je u on line reţimu rada pridruţiti
javni kljuĉ sa njihovim vlasnikom. Uobiĉajen naĉin za pridruţivanje
javnih kljuĉeva sa njihovim vlasnicima je pomoću digitalnog sertifikata.
Digitalni sertifikat je elektronski dokument koji povezuje javni kljuĉ sa
imenom vlasnika na poverljiv i bezbedan naĉin, koristeći usluge
poverljivog provajdera zaštite (TTP), poznatog kao sertifikaciono telo -
CA (Certificatio Authority), koji garantuje ovaj odnos.

PKI sistem je koherentna implementacija tehniĉkih, operativnih i legalnih

(upravljaĉkih) komponenti zaštite, koja omogućava stranama u
transakciji da veruju u povezanost izmeĊu javnog kljuĉa i imena
vlasnika. Mera u kojoj se korisnik moţe osloniti na ovu povezanost
zavisi od zrelosti procesa sa kojim CA izdaje sertifikate i verifikuje
identitet korisnika kojima se sertifikat izdaje.

- 179 -
Generalno, PKI ništa ne govori o nivou meĊusobnog poverenja korisnika,
ili sa kakvim poverenjem će neki korisnik reagovati dok koristi digitalni
sertifikat. Iako se proverama (da fiziĉka lica nemaju zakonskih problema,
ili da organizacije rade u zakonskim okvirima i sl.), koje CA vrši pre
izdavanja sertifikata, u izvesnoj meri mogu obezbediti odnosne strane sa
indikacijama o nivou poverenja koje klijenti meĊusobno mogu imati, ova
praksa nije obavezan zahtev za CA.

Da bi se odnosnim stranama obezbedilo dovoljno informacija za

donošenje odluke o korišćenju sertifikata, CA opisuje praksu i procese
koji koriste za izvršavanje dnevnih poslova u dokumentu Izjava o praksi
sertifikacije (CPS-Certificate Practice Statement). Pored toga, pravila i
ograniĉenja korišćenja svakog posebnog tipa sertifikata daju se u
pratećem dokumentu Politika sertifikacije. U ovoj oblasti postoji dosta
zrelih standarda i uputstava, ali naţalost svi standardi nisu meĊusobno
koherentni [11], [15], [16].

U pogledu tehniĉkih komponenti, većina implementacija PKI sistema

ukljuĉuje CA, Telo za registraciju –RA (Registration Authority) i Imenik
(Directory - tipa X500 ili LDAP). Malo je nezgodno što se izraz CA
koristi istovremeno za opis organizacije koja upravlja i administrira PKI
sistem u celini i komponente zaštite za izdavanje i upravljanje
sertifikatima, ali je korektna interpretacija obiĉno evidentna iz konteksta.
Pored ova tri osnovna modula, PKI sistem moţe implementirati i dodatne
opcione module, kao što su:

- hardversko softverski moduli (HSM),

- smart kartice i tokeni za bezbedno skladištenje kriptografskih
informacija,
- kriptografski akceleratori za ubrzavanje performansi,
- OCSP (On-line Certification Status Protocol) responder za
verifikaciju statusnih informacija o sertifikatu u realnom
vremenu,
- programi za validaciju transakcija i drugi programi za podršku.

Razliĉiti PKI moduli sa komentarima o zajedniĉkom radu prikazane su

na slici Sl. 1.4.

- 180 -
 Rut CA

Poverljiv
faktor PKI
Server

RA vrši proveru i
Korisnik registruje RA rešava zahteve
ili opoziva CA za registraciju
sertifikat sa RA i opoziv
Korisnik

Server
CA
LDAP
Workstation Server

CA potpisuje
Drugi korisnički Server
sertifikat i
sertifikati
informacije o
uzimaju se iz
opozivu za LDAP
LDAP servera

Sl. 1.4. Kljuĉni moduli PKI sistema

CA modul je najznaĉajnija komponenta PKI, pošto potpisuje sertifikat i

statusne informacije o sertifikatu. Da bi se ograniĉio rizik, standardna
opcija je da se razvija i implementira rut CA, koje je stub poverenja cele
infrastrukture. Rut CA ima samo-potpisan sertifikat, a javni kljuĉ je
objavljen u nekoliko raspoloţivih repozitorijuma da bi se obezbedilo
nekoliko referentnih izvora (ako se jedan ili više kompromituje). Rut CA
potpisuje sertifikate drugih CA koji potpisuje sertifikate korisnicima i
niţim CA u hijerarhijskoj strukturi u svojim domenima zaštite. Rut CA
ograniĉava dubinu hijerarhije (basic constraint). Ovaj parametar definiše
koliko niţih CA moţe biti formirano po vertikali ispod rut CA.

RA podrţava CA vodeći raĉuna o najvećem delu administrativnih

poslova koji prate izdavanje i opoziv sertifikata. Kao takav, RA deluje
kao posrednik izmeĊu korisnika i CA. Detaljniji opis funkcionalnosti CA
i RA dat je u PRILOGU I 9B.

Dok su sertifikati skoro uvek uskladišteni u direktorijima (Imeniku),

nema ĉvrstih i urgentnih zahteva da se tako radi. MeĊutim, oĉekuje se da
će aplikacije razvijene da iskoriste prednosti PKI sistema koristiti
jednostavan protokol za pristup direktorijumu LDAP (Lighweight
Directory Access Protocol) i izvlaĉenje informacija o sertifikatima.
Funkcija imenika je jednostavno da objavi statusne informacije o
sertifikatima i opozvanim sertifikatima.

- 181 -
1.7.2. Smart kartice i kriptografski moduli
Za visoku bezbednost IKT sistema, u prvom redu koriste se smart
kartice i kriptografski moduli za zaštitu kriptografskih tajni. Sa aspekta
fiziĉkih operativnih karakteristika, postoje tri glavne klase smart kartica,
[8]:
- kontaktne kartice, koje zahtevaju fiziĉki kontakt sa ĉitaĉem
kartica;
- beskontaktne kartice, kapacitivno ili induktivno spregnute i
- kombinovane kartice, koje obezbeĊuju oba naĉina rada.
Iako su objavljene bezbednosne ranjivosti smart kartice (napadi
diferencijalnom analizom snage i optičkom indukcijom greške), smart
kartice se generalno smatraju veoma bezbednim okruţenjem za
skladištenje kriptografskih kljuĉeva i drugih tajnih informacija na strani
korisnika. Na raspolaganju je veliki broj ureĊaja sa smart karticama tipa
bankarskih kartica, iako personalizacija i distribucija zahtevaju znaĉajne
investicije (zbog relativno niske konkurencije proizvoda u ovoj oblasti).
U stvari, smart kartiĉna tehnologija u velikoj meri je doprinela razvoju
koncepta elektronskog plaćanja.
Smart kartice za skladištenje kriptografskih tajni na strani korisnika,
obiĉno štiti pristup podacima sa zahtevom za unošenje PIN koda ili
nekog biometrijskog parametra (npr. otisak prsta, retine oka i.t.d.) za
otkljuĉavanje interfejsa ĉime se implementira dvoslojna ili troslojna
autentifikacija korisnika ciljnom OS-u. U ovom sluĉaju od korisnika se
zahteva nešto što imaju (smart kartica) za identifikaciju, nešto što znaju
(PIN kod), ili nešto što poseduju (otisak prsta, na primer) da bi se izvršila
jaka autentifikacija OS-u. Korisnik nema pristup samom kljuĉu u smart
kartici i ne moţe ga otkriti drugom licu, optuţujući pri tome da je to
uradio neko drugi.
Kriptografske aplikacije koriste smart kartice na dva moguća naĉina:
1. memorijske kartice, za skladištenje kljuĉa, dok se kriptografske
operacije izvršavaju izvan kartice, u aplikaciji na host platformi.
2. mikroprocesorske kartice (kriptokartice) koje izvršavaju bezbedno
skladištenje kljuĉa i omogućavaju kriptografske operacije na samoj
kartici. Aplikacije interaktivno rade sa karticom preko API (Application
Programming Interface). Definisano je nekoliko razliĉitih interfejsa npr.

- 182 -
PKCS#11, PC/SC, OCF i CDSA. Izbor zavisi od izvora razvojnog
modela.
Za zaštitu aplikacija poţeljne su kriptokartice, jer kljuĉevi nikada ne
napuštaju bezbedno okruţenje. MeĊutim, paţnju treba obratiti kod
implementacije rešenja: PIN ne sme prolaziti kroz OS, što zahteva
postojanje eksternog PIN ĉitaĉa (interfejsa). Ovaj princip ilustrovan je na
Sl. 1.5, [23].
Spoljni čitač sa Spoljni čitač bez
PIN pad-om PIN pad-a

Aplikacije
PIN
Aplikacije

Snifer
OS OS
(netbus)

PKCS#11 PKCS#11

PIN Smart Smart

kartica kartica

Čitač smart kartice Čitač smart kartice

Sl. 1.5. Korišćenje kriptokartice sa eksternim ĉitaĉem kartica

Smart kartice su dobar izbor za zaštitu kriptografskih tajni na strani

klijenata, ali nisu pravi izbor za operacije na serverskoj strani, iako se
ĉesto koriste za skladištenje kljuĉeva koje koriste administratori za
pristup zaštićenom serveru (gde je administrator u ulozi klijenta). Na
serverskoj strani bolja opcija je skladištenje kljuĉeva na tzv. HSM
(Hardware Security/Storage Module). U ovoj oblasti vaţan standard je
NIST FIPS 140- 1 i 2 koji pokriva ukupno 11 oblasti dizajna i
implementacije kriptografskih modula. Standard se koristi za rangiranje
bezbednosnih ureĊaja na 4 bezbednosna nivoa: bezbednosni nivo 1
obezbeĊuje najmanji nivo zaštite, a nivo 4 – najveći nivo zaštite.
Kriptografski moduli su rangirani na osnovu serije testova zvanih DTR
(derivirani zahtevi za testove) za pomenuti standard.

Mogućnost izvršavanja biznisa preko Interneta donosi praktiĉno

neograniĉen broj klijenata, što zahteva veću skalabilnost aplikacija i
kriptografskih rešenja. Za ovu svrhu koriste se kriptografski akceleratori
– specijalizovani HSM, koji kombinuju bezbedno skladištenje kljuĉeva
sa kriptografijom visokih performansi, a namenjeni su da obezbede više
performanse kriptografskih aplikacija.

- 183 -
1.7.3. Autentifikacioni ureĎaji i protokoli

Autentifikacioni ureĎaji koriste se u procesu autentifikacije, a

obezbeĊuju korisniku neki fiziĉki objekt (identifikator) koji se zahteva za
uspešno kompletiranje procesa autentifikacije. Do sada većina ureĊaja za
autentifikaciju spada u sledeće kategorije: smart kartice (opisane u
prethodnoj sekciji), biometrijski ureĎaje i tokene.

Biometrijske tehnologije obuhvataju tehnike: provere otiska prsta,

provere geometrije ruke, skeniranja mrežnjače, prepoznavanja govora,
prepoznavanja lica i facijalne termografije. Svi mehanizmi zaštite
fiziĉkog i logiĉkog pristupa RM/RS uvek su kompromis izmeĊu potreba
za zaštitom i potreba pristupa regularnih korisnika sa što većim
komforom. Biometrijski ureĊaji verifikuju identitet korisnika na bazi 1 li
više fiziĉkih atributa, jedinstvenih biometrijskih parametara. Osnovni
kriterijumi za izbor biometrijskih tehnika za proveru autentiĉnosti mogu
biti: performanse i pouzdanost, pogodnost za primenu (kompleksnost
korisničke upotrebe), mogućnosti (sposobnosti) korisnika, korisnička
prihvatljivost i troškovi nabavke.

Iako se preporuĉuje autentifikacija korisnika sa biometrijskim

parametrima, ovu primenu prate brojni problemi: visok cena, korisniĉka
neprihvatljivost, visok stepen grešaka, nemogućnost autentifikacije
nehumanih entiteta, neotpornost na napade (npr. otisak prsta) i dr.

Tokeni se mogu svrstati u dve kategorije: za bezbedno skladištenje

kriptografskih informacija i tokene koji služe kao priručni ureĎaji.

Prvi su alternativa smart karticama. Drugi su opremljeni sa malim

displejom i tastaturom i generalno ne moraju se povezivati na
korisnikovu radnu stanicu. UreĊaj se konfiguriše sa autentifikacionim
serverom pre izdavanja korisniku, što omogućava serveru i tokenu da
podele kriptografske tajne, kao osnovu za autentifikaciju. Korisnik unosi
svoj pasvord ili PIN za pristup tokenu, a token na displeju pokaţe
autentifikacione informacije potrebne za pristup autentifikacionom
serveru, koji zahteva od korisnika da se autentifikuje. Ovu informaciju
korisnik unosi u svoju radnu stanicu i kompletira proces autentifikacije.

Iako se autentifikacioni protokoli meĊusobno razlikuju dve osnovne

grupe su: vremenski sinhronizovani i asinhroni protokoli. Prvi se oslanja

- 184 -
na sinhronizaciju ĉasovnika na tokenu i autentifikacionom serveru, a
asinhroni ureĊaji koriste protokole tipa upit-odgovor za identifikaciju
korisnika (tipa Kerberos) i nisu osetljivi na nesinhronizaciju ĉasovnika.

1.8. Zaštita beţiĉno povezanih lokalnih mreţa (WLAN)

Svi tipovi beţiĉnih mreţa (WLAN) imaju iste osnovne

bezbednosne probleme-koriste radio frekvencije za prenos informacija,
što lako moţe kompromitovati informacije na prenosnom putu. WLAN,
klasiĉan Ethernet LAN bez kablovske infrastrukture, sa velikom uštedom
komunikacione infrastrukture i lakoćom implementacije, ima najveću
praktiĉnu primenu. Beţiĉna tehnologija je izgraĊena na bazi IEEE
802.11b standarda u SAD i GSM (Groupe Spécial Mobile) standarda u
EU.

WLAN standard IEEE 802.11b, [30], prenosi informacije na 2,4 GHz,

ima maksimalni propusni kapacitet 11Mb/s i implementiran WEP
(Wireless Equivalent Protocol) protokol za zaštitu prenosa, koji je
dizajniran da obezbedi iste karakteristike zaštite kao i prenos fiziĉkim
putevima: raspoloživost (kontrolu pristupa), poverljivost i integritet.
MeĊutim, već 2001. objavljeno je da hakeri uspešno krekuju i modifikuju
WEP poruke na WLAN mreţama na više naĉina. Problem je što se
sistem kriptozaštite (RC4 algoritam) moţe probiti i omogućiti pristup
mreţi, [10].

Pretnje za WLAN su brojne. Implementacija DoS napada je izuzetno

laka. Tako na primer, mikrotalasna pećnica sa premošćenim
mehanizmom za zatvaranje vrata kada moţe raditi sa otvorenim vratima,
stvara smetnju od 1000 W na istoj frekvenciji kao i ureĊaji standarda
802.11b. Faktori rizika WLAN mreţe mogu se svrstati u 7 osnovnih
kategorija: napadi ubacivanjem u tok saobraćaja (insertion attacks),
ometanje (Jamming), kriptoanalitiĉki napad (Encryption Attacs),
izviĊanje i intercepcija saobraćaja (war driving), kolaborativni rad
mobilnih ureĊaja (moguć prenos malicioznog kôda u RM), mogućnost
rekonfiguracije sistema i napada brutalnom silom. Svaki od navedenih
faktora rizika i potencijalnih proboja WLAN sistema mogu se redukovati
ili izbeći sa propisnim korišćenjem politike zaštite i najbolje prakse
zaštite WLAN.

- 185 -
GSM evropski sistemi mobilne telefonije imaju brojne ranjivosti: SIM
kartice, SMS servisa, GPRS servisa i WAP (Wireless Application
Protocol) standardnog protokola, [20], [30].

Treća (3-G) generacija tehnologije beţiĉnih sistema koriguje sve uoĉene

bezbednosne ranjivosti navedenih standarda. 3-G tehnologija usmerena je
na poboljšanje komunikacije podataka i glasa beţiĉnim putem koristeći
bilo koji od raspoloţivih standarda. Neposredni cilj je povećanje brzine
prenosa sa 9,5 Kbps na 2 Mbps i povećanje frekvencije prenosa na 5,1
GHz. U sistemu prenosa i zaštite cilj je razviti skalabilan sistem koji se
moţe nadograditi sa poboljšanim kontrolama zaštite, kada je potrebno.
Identifikovani tipove napada na WLAN mreţe sa nosećim frekvencijama
od 2 GHz i 2,5 GHz, u 3-G WLAN mreţi su eliminisani. Sistem zaštite 3-
G WLAN zasniva se na zaštiti GSM standarda sa sledećim vaţnim
izmenama:

- onemogućen je napad na baznu stanicu sa laţnim

predstavljanjem,
- povećana je duţina kriptološkog WEP kljuĉa i dopušta se
implementaciju jaĉeg kriptološkog algoritma za zaštitu
poverljivosti i integriteta podataka,
- ukljuĉeni su mehanizmi zaštite unutar i izmeĊu WLAN mreţa,
- mehanizmi zaštite su smešteni u sviĉerima, a ne u baznoj stanici
kao u GSM mreţi, štite vezu izmeĊu bazne stanice i sviĉera,
- mehanizmi za zaštitu integriteta i identifikaciju terminala,
integrišu se od samog poĉetka razvoja WLAN,
- dato je uputstvo za izbor autentifikacionog algoritma, koji nije
definisan i
- u toku roming veze izmeĊu mreţa, kao što su GSM i 3GPP,
apliciran samo nivo zaštite kojeg podrţava tehnologija smart
kartica.

Sistem zaštite 3-G WLAN je znatno bolji od zaštite GSM mreţa, ali se
mogući napadi nikako ne mogu potceniti, a potencijalne slabosti 3-G
WLAN mreţa mogu biti: logovanje na lažnoj baznoj stanici i forsiranje
komunikacije bez kriptozaštite, [5], [10].

- 186 -
2. REZIME

Servis mreţne autentifikacije i autorizacije obavljaju mreţni

autentifikacioni protokoli i autentifikacioni i autorizacioni serveri. Kako
se podaci, koji se u otvorenoj formi prenose preko TCP/IP - glavnog
mreţnog protokola, mogu lako prisluškivati (uhvatiti i analizirati), koriste
se zaštitni protokoli tipa: SSL (Secure Socket Layer) protokol (koji nije
pravi primer autentifikacionog protokola) za unošenje pasvorda preko
uspostavljene bezbedne sesije u pristupu web aplikacijama i tipa
Needham – Schroeder protokola (Kerberos sistema u Windows NT 4.0
OS), koji rade uglavnom na principu upita-odgovora.

Autentifikacioni serveri se koriste za centralizaciju procesa

autentifikacije u raĉunarskoj mreţi. Autorizacioni serveri idu korak dalje
pridruţujući skup privilegija ili prava pristupa autentifikacionim
entitetima (korisnici - ljudi, programi). Iako A&A serveri nisu nuţno
obavezni u sistemima za kontrolu pristupa sa udaljenih mreţnih lokacija,
oni se uobiĉajeno koriste za podršku ovom servisu. Tipiĉan primer kako
serveri za A&A rade ukljuĉuje udaljenog korisnika, koji bira broj servera
organizacije preko PSTN (javne telefonske) mreţe. Postoje dva glavna
protokola koji se danas koriste za udaljeni pristup: RADIUS (Remote
Authentication Dial In User Service) protokol i TACACS + protokol.

Integritet računarske mreže obezbeĊuje se implementacijom detektora

upada (NIDS), analizom incidenta i sa kapacitetima za upravljanje
incidentom i oporavak sistema u Intranet mreţi organizacije i skenera
saobraćaja u RM. NIDS i mreţni skeneri rade na istim principima kao
IDS i skeneri RS, s tim da otkrivaju napade i ranjivosti RM. Skeneri
telefonskih veza, komercijalni razvoj hakerskih alata tzv.war dialing
programa, koriste se za identifikovanje potencijalnih ranjivosti sistema
preko telefonske linije.

Servis kontrole pristupa RM izvršavaju barijere (firewals), ureĊaji ili

konstrukcije ureĊaja koje nameću politiku kontrole pristupa izmeĊu dve
ili više segmenata RM i obezbeĊuju arhitekturno rešenje mreţne zaštite
po dubini. Postoje dve znaĉajne klase barijera koje rade na razliĉitim
principima, ali postiţu sliĉne rezultate: na principu potpune kontrole
„stanja― konekcije i filtriranja rutiranih IP paketa i na aplikativnom sloju
(gateway) ili proksi barijere, koje ne rutiraju direktno pakete. Sve više
proizvoĊaĉi kombinuju karakteristike obe barijere. Proksi serveri

- 187 -
funkcionišu sliĉno aplikativnim gateway barijerama, ali kontrolišu
konekcije koje dolaze iz RM. Najĉešći u praksi su web proksi serveri.
Striktno govoreći, proksi serveri su pre višefunkcionalni mehanizmi, sa
vaţnom bezbednosnom funkcionalnosti.

Monitoring RM obezbeĊuju mreţni sistemi za detekciju upada (NIDS-

Network Intrusion Detection Systems), koji u većini sluĉajeva rade
mreţnom sloju, detektuju sisteme nezavisno od OS i omogućavaju zaštitu
velikog opsega ciljnih platformi.

Servis zaštite poverljivosti i integriteta podataka u RM izvršavaju

kriptografski mehanizmi i zaštitni protokoli, koji izvršavaju jedan ili više
od sledećih mreţnih servisa zaštite: autentifikaciju, zaštitu poverljivosti,
zaštitu integriteta i neporecivost. Zaštita poverljivosti mrežnih podataka
postiţe se šifrovanjem. Standardni pristup je korišćenje PKI kriptografije
za razmenu simetriĉnog kljuĉa i korišćenje simetriĉnog kljuĉa za
šifrovanje podataka. Primeri mreţnih protokola zaštite su: SSL (Secure
Socket Layer) i TLS (Transport Layer Security) i IPsec protokol, koji je
najpoţeljniji za implementaciju VPN servisa.

Zaštita integriteta u mrežnom okruženju komplikuje se ĉinjenicom da se

moraju razmatrati dva tipa integriteta: integritet podataka, koji je
razumljiv i integritet sesije, namenjen da obezbedi da karakteristike
komunikacione sesije nisu modifikovane ni na koji naĉin.

Infrastrukturne komponente mrežne zaštite su infrastruktura sa javnim

ključem (PKI), poznata i kao asimetriĉna kriptografija, smart kartice i
kriptografski moduli za zaštitu kriptografskih tajni i autentifikacioni
ureĎaji. PKI, jedna od najbitnijih komponenti zaštite savremenih RM,
koristi asimetriĉnu kriptografiju koja javno distribuiranom kljuĉu
pridruţuje jedinstveni privatni kljuĉ svakom uĉesniku, obezbeĊuje okvir
za protokole zaštite transakcija i omogućava implementaciju servisa
digitalnog potpisa (DS), neporicanja aktivnosti, zaštite poverljivosti i
integriteta informacija i jake autentifikacije. Osnovne komponente
(moduli) PKI su: sertifikaciono telo – CA, Telo za registraciju –RA
(Registration Authority) i Imenik (Directory - tipa X500 ili LDAP).

- 188 -
Za visoku bezbednost IKT sistema, koriste se smart kartice i
kriptografski moduli - HSM (Hardware Security/Storage Module) za
zaštitu kriptografskih tajni. Za skladištenje kriptografskih tajni na strani
korisnika koriste se smart kartice, a HSM na serverskoj.

Kriptografski akceleratori su specijalizovani HSM, koji kombinuju

bezbedno skladištenje kljuĉeva sa kriptografijom visokih performansi i
obezbeĊuju veću skalabilnost kriptografskih aplikacija.

Autentifikacioni ureĎaji obezbeĊuju korisniku neki fiziĉki

identifikacioni objekat koji se zahteva za uspešno kompletiranje procesa
autentifikacije: smart karticu, biometrijski ureĎaj, ili token za bezbedno
skladištenje kriptografskih informacija ili kao priruĉni ureĊaj za
autentifikaciju.

Sve beţiĉne mreţe inherentno su nebezbedne pošto koriste radio

frekvencije za prenos informacija, što lako moţe kompromitovati
informacije na prenosnom putu. Beţiĉna lokalna mreţa - WLAN
(Wireless LAN), ili klasiĉan Ethernet LAN bez kablovske infrastrukture,
koji se lako implementira i obezbeĊuje veliku uštedu komunikacione
infrastrukture, ima najveću praktiĉnu primenu. Beţiĉna tehnologija
WLAN izgraĊena je na bazi IEEE 802.11b standarda u SAD i GSM
(Groupe Spécial Mobile) standarda u EU. WEP (Wireless Equivalent
Protocol) protokol za zaštitu prenosa, koji je dizajniran da obezbedi iste
karakteristike zaštite kao i prenos fiziĉkim putevima: raspoloživost
(kontrolu pristupa), poverljivost i integritet, pokazao je brojne slabosti
(RC4 algoritma).

Treća (3-G) generacija tehnologije beţiĉnih sistema koriguje sve uoĉene

bezbednosne ranjivosti navedenih standarda WEP protokola za zaštitu
prenosa. 3-G tehnologija usmerena je na poboljšanje komunikacije
podataka i glasa beţiĉnim putem koristeći bilo koji od raspoloţivih
standarda.

- 189 -
3. KLJUĈNI TERMINI

Autentifikacioni protokoli: standardno ugraĊeni su u sam proces

razmene podataka; koriste dodatne mere zaštite, kao što su šifrovanje za
zaštitu poverljivosti, ili mehanizmi za zaštitu integriteta i neporecivosti.
Autentifikacioni serveri: koriste se za centralizaciju procesa
autentifikacije u raĉunarskoj mreţi.
Autentifikacioni ureĊaji: koriste se u procesu autentifikacije, a
obezbeĊuju korisniku neki fiziĉki objekt (identifikator) koji se zahteva za
uspešno kompletiranje procesa autentifikacije; dele se na: smart kartice,
biometrijski ureĊaji i tokeni.
Autorizacioni serveri: pridruţuju skup privilegija ili prava pristupa
autentifikacionim entitetima (korisnici - ljudi, programi).
Biometrijski ureĊaji: verifikuju identitet korisnika na bazi 1 li više
fiziĉkih atributa, jedinstvenih za tog korisnika kao što su: otisak prsta,
otisak mreţnjaĉe oka (retine), analiza otkucaja tastature, prepoznavanje
glasa i skeniranje lica.
Hardversko-softverski modul: HSM (Hardware Storage Module or H.
Software M.) koji sluţi na serverskoj strani za skladištenje kljuĉeva.
Infrastruktura sa javnim kljuĉem: PKI-Public Key Infrastructure,
asimetriĉna kriptografija sa parom javnog; obezbeĊuje okvir za
protokole zaštite transakcija i implementaciju servisa digitalnog potpisa,
neporicanja aktivnosti, zaštite integriteta i jake autentifikacije; glavni
moduli su TTP digitalnih sertifikata, sertifikaciono telo - CA, telo za
registraciju –RA (Registration Authority) i Imenik (Directory - tipa X500
ili LDAP).
Integritet sesije: namenjen je da obezbedi da karakteristike
komunikacione sesije nisu modifikovane ni na koji naĉin.
Kriptografski akceleratori: specijalizovani HSM, koji kombinuju
bezbedno skladištenje kljuĉeva sa kriptografijom visokih performansi, a
namenjeni su da obezbede više performanse kriptografskih aplikacija.
Kriptografski protokoli: imaju najznaĉajniju primenu za zaštitu
podataka na prenosnom putu kroz potencijalno ne-prijateljske raĉunarske
mreţe implementiraju i izvršavaju jedan ili više sledećih mreţnih servisa
zaštite: autentifikaciju, zaštitu poverljivosti, zaštitu integriteta i
neporecivost.
Mehanizmi za infrastrukturnu podršku: ĉine ih infrastruktura sa
javnim kljuĉem – PKI, autentifikacioni ureĎaji (smart kartice,
kriptografski moduli, biometrijski ureĊaji, tokeni) i autentifikacioni
protokoli (vremenski sinhronizovani i asinhroni).

- 190 -
Mreţne barijere (Firewalls): ureĊaji ili konstrukcije ureĊaja koje
nameću politiku kontrole pristupa izmeĊu dve ili više segmenata RM;
arhitekturno rešenje mreţne zaštite po dubini.
Mreţno orijentisani alati: mehanizmi i protokoli za zaštitu raĉunarske
mreţe-RM.
Proksi serveri: rade sliĉno aplikativnim gateway barijerama, ali
kontrolišu veze koje dolaze iz RM organizacije.
Server mreţnog pristupa: NAS – Network Access Server, prima vezu
od PSTN i dopušta konekciju na zahtevani interni host, nakon
verifikacije identiteta korisnika i primene neke restrikcije.
Skeneri telefonskih veza: predstavljaju komercijalni razvoj hakerskih
alata tzv. war dialing programa koji se koriste za identifikovanje
potencijalnih ranjivosti sistema preko telefonske linije; konceptualno su
sasvim sliĉni skenerima ranjivosti RM.
Skeneri zaštite raĉunarske mreţe: sliĉni su skenerima zaštite
raĉunarskog sistema, s tim sa otkrivaju ranjivosti raĉunarske mreţe
(RM).
Smart kartice: autentifikacioni ureĊaj sa ĉitaĉem; kartica sa
mikroĉipom: memorijske za skladištenje kljuĉa, a sve kriptografske
operacije izvršavaju se izvan kartice, u aplikaciji na host platformi, ili
mikroprocesorske (kriptokartice) koje izvršavaju bezbedno skladištenje
kljuĉa i omogućavaju kriptografske operacije na samoj kartici.
Tokeni : autentifikacioni ureĊaji za bezbedno skladištenje kriptografskih
informacija, kao smart kartice, ili priruĉni ureĊaji za autentifikaciju.

- 191 -
4. LITERATURA

1. @stake, http://www.atstake.com, 2006.

2. Bace R., Mell P., Intrusion Detection Systems, NIST SP 800-
31, http://www.csrc.nist.gov/publications, 2006.
3. Burns,Jim Evolution of WLAN Security,
http://www.mtghouse.com/MDC_Evolving_Standar
ds.pdf, 2004.
4. Carrel D., i Grant L., The TACAS+ Protocol,
http://casl.csa.iisc.ernet.in/Standards/internet-drafts/draft-
grant-tacas-02.txt, 2003.
5. Christopher W.Klaus, Wireless LAN Security FAQ,
http://www.iss.net/wireless/WLAN_FA Q.php, 2003.
6. COAST - Computer Operations, Audit, and Security Technology,
Pardu univerzitet, SAD, http://www.cs.purdue.edu/coast/#archive ,
2003.
7. Curtin M., M.J. Ranum, Internet Firewalls: FAQ,
http://www.interhack.net/pubs/fwfaq., 2003.
8. Ferrari J. i dr., Smart Cards: A case Study,
http://www.redbooks.ibm.com/redbooks/pdfs/sg245239.pdf,
avgust 2003.
9. Frankel Sheila, An Introduction to IP sec, NIST ITL Buliten,
http://www.csrc.nist.gov/buliten, 2001.
10. Heyer Jürgen, WLAN Security: Wide Open,
http://www.tomsnetworking.com/network/20020719
/index.html, 2004.
11. Housley R. i dr., Internet X509 Public Key Infrastructure:
Certificate and CRL Profile (RFC 2459),
http://www.ietf.org/rfc/rfc2459.txt.
12. http://www.csrc.nist.gov/encription.
13. http://www.csrc.nist.gov/encryption/shs/FR_180-2.pdf.
14. http://www.ietf.org/rfc/rfc2246.txt.
15. http://www.ietf.org/rfc/rfc2510.txt.
16. http://www.ietf.org/rfc/rfc2527.txt.
17. http://www.itl.nist.gov/fipspubs/fip180-1.htm.
18. http://www.rsasecurity.com.
19. IDWG (Intrusion Detection Working Group),
http://www.ietf.org/html.charters/idwg-charter.html, 2005.

- 192 -
20.Karygiannis T., Owens L., Wireless Network Security 802.11,
Bluetooth and Handheld Devices, NIST SP 800-48,
http://www.csrc.nist.gov/publications, novembar 2002.
21. Kelm S., The PKI page, http://www.pki-page.org.
22. Ou George, Understanding the updated WAP and WAP2
standards, http://blogs.zdnet.com/Ou/?p=67, 2002
23. Purser S., A practical Guide to Managing Information
Security, Artech House, Boston-London,
www.artechhouse.com, 2004.
24. RFC 1320 i RFC 1321, http://www.icann.rfceditorc.org.
25. RFC 2196, Site Security handbook,
http://www.faqs.org/rfc/rfc2196.html, 2003.
26. Rigney C., i dr., Remote Authentication Dial In User Service
(RADIUS) RFC2138), http://www.faqs.org/rfc/rfc2138.html ,
2003.
27. Ruth A, Hudson K., Sertificat Security +, MicrosoftCo., CET
Beograd, 2004.
28. SANS Institute, Sans IDS FAQ,
http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm
, 2006.
29. Scheiner Bruce, Applied Cryptography: Protocols Algorithms
and Source Code in Cryptography, 2nd edition, New York,
John Wiley and Sons, Inc., 1996.
30.Wikipedia, http://en.wikipedia.org/wiki/802.11i ,
2003.

- 193 -
10. KONCEPT KONTROLA SISTEMA ZAŠTITE INFORMACIJA

0. UVOD

Kada završite ovo poglavlje razumećete:

- značenje termina i namenu koncepta kontrola zaštite

- procenu pokrivanja pretnji kontrolama zaštite
- strukturu upravljačkih, operativnih i tehničkih kontrola
- metod izbora kontrola zaštite za sistem osnovne zaštite
- metod bezbednosne kategorizacije i klasifikacije objekata IS

Prema podacima (NIST, 2003) godine, oko 99% svih

registrovanih upada u IKT sisteme rezultat su korišćenja poznatih
ranjivosti OS ili grešaka konfiguracije, za koje su bile na raspolaganju
mere zaštite. Izbor odgovarajućih upravljačkih, operativnih i tehničkih
kontrola zaštite IKT sistema vaţan je zadatak za svaku organizaciju, a
posebno za drţavne organe u sistemu e-Uprave, koji procesiraju
informacije svih vrsta bezbednosne klasifikacije i sadrţe objekte svih
vrsta bezbednosnih kategorija. Pri izboru kontrola zaštite vaţno je
obezbediti: adekvatne kontrole za zaštitu IKT sistema, implementaciju ili
plan implementacije tih kontrola i oĉekivani nivo zaštite (bezbednosne
garancije).

Cilj definisanja kataloga kontrola zaštite je da se obezbede katalozi

skalabilnih skupova kontrola zaštite i olakša izbor adekvatnih kontrola za
konkretan sistema zaštite, na osnovu rezultata procesa analize rizika.
Koncept kataloga kontrola zaštite obezbeĊuje:

 konzistentniji, uporedljiviji i ponovljiviji pristup za izbor i

specifikaciju kontrola zaštite, rentabilnih za ublaţavanje faktora
rizika procenjenih u procesu analize rizika;
 preporuke za sistem osnovne zaštite (eng. baseline), kategorizovane
prema standardu za bezbednosnu kategorizaciju i klasifikaciju
objekata IKT sistema;
 adaptivnost i dinamiĉko proširenje prema zahtevima prakse zaštite za
upravljanje tehnološkim, organizacionim i upravljaĉkim promenama
u realnim IKT sistemima i
 bazu za razvoj tehnika za verifikaciju i procedura za odreĊivanje
efikasnosti kontrola zaštite.

- 194 -
Pre izbora kontrola sistema zaštite, preporuĉuje se da organizacija izvrši
bezbednosnu kategorizaciju i klasifikaciju objekata IKT sistema i analizu
rizika.

- 195 -
1. POKRIVANJE PRETNJI KONTROLAMA ZAŠTITE

1.1. Opis izvora pretnji

Prva aktivnost u procesu izbora kontrola zaštite je opis izvora

pretnji. Da bi se razumeli vrsta i intenzitet pokrivanja pretnji
primenjenim kontrolama zaštite, treba odrediti koje se potencijalne
pretnje nameravaju, a koje ne nameravaju ublaţiti ili spreĉiti izabranim
kontrolama zaštite. U tom smislu korisna je taksonomija potencijalnih
pretnji za IKT sistem, koja opisuje kljuĉne posledice uticaja sledećih
pretnji (v. G. II, p.1): greške, prirodni dogaĎaji, namerni napadi. Greške
(ljudi, mašina) mogu uticati na sistem od minornih degradacija
performansi do kompletnog gubitka servisa sistema. Prirodni dogaĊaji
mogu izazvati oštećenja ili uništenje sistema, zavisno od intenziteta i
obima dogaĊaja. Namerni napadi, obiĉno (ali ne uvek) maliciozni, sa
promenljivim stepenom intenziteta, mogu biti izvor potencijalnih
oštećenja objekata sistema, aplikacija ili informacija. Namerne pretnje
obiĉno se karakterišu prema: tipu, sposobnostima, resursima i namerama
napadača, [10].

1.2. Procena pokrivanja prirodnih grešaka/dogaĊaja

U izabranom osnovnom sistemu zaštite, procena pokrivanja prirodnih

pretnji vrši se za tri osnovna efekta kontrola zaštite:

1. obezbeĊenje adekvatne zaštite i pokrivanja navedenih pretnji;

2. obezbeĊenje adekvatne zaštite i pokrivanja navedenih pretnji u
kombinaciji sa drugim kontrolama zaštite i ostalim opštim
faktorima smanjenja rizika i
3. ne obezbeĊenje adekvatne zaštite i pokrivanja navedenih pretnji.

Da bi se generisale adekvatne kontrole za sistem osnovne zaštite treba

izvršiti analizu rizika u ranoj fazi razvoja ţivotnog ciklusa sistema. Ako
se pokaţe da su procenjena pokrivanja pretnji neadekvatna, kontrole za
sistem osnovne zaštite mogu se poboljšati povećanjem nivoa njihove
robusnosti ili dodavanjem novih kontrola. Proces izbora kontrola zaštite
treba voditi na osnovu procene rizika i prihvatljivog nivoa rizika. Primer
metoda procene pokrivanja pretnji osnovnim kontrolama zaštite prikazan
je u PROLOGU I 10 A: grešaka i prirodnih dogaĊaja u tabeli T.1, za
lokalne napade u T. 2, a za mreţne napade u T. 3.

- 196 -
2. ODREĐIVANJE KVALITETA KONTROLA ZAŠTITE

Kvalitet sistema upravljaĉkih, operativnih i tehniĉkih kontrola

zaštite odreĊuju karakteristike, organizacija i struktura pojedinaĉnih
kontrola zaštite i njihova adaptivnost (fleksibilnost – mogućnost
zamenljivosti i skalabilnost - mogućnost proširivanja). Kvalitet kontrole
zaštite osnov je za davanje bezbednosne garancije (assurance) za rad
IKT sistema u procesu sertifikacije i akreditacije implementiranog
sistema zaštite, kao i za sticanje poverenja da izabrane kontrole zaštite
rade na predviĊen naĉin na zaštiti sistema i informacija koje sistem
procesira, skladišti i prenosi, [7].
2.1. Osnovne karakteristike kontrola zaštite
Kontrola zaštite je krajnja klasifikacija mehanizama zaštite, a
implicira da svaki mehanizam (servis, sistem) zaštite ima punu vrednost
samo ako se moţe kontrolisati. Kontrola zaštite je tipiĉno neka funkcija
dizajna sistema i ne odnosi se samo na tehniĉke mehanizme zaštite koji
imaju kibernetiĉku kontrolnu povratnu spregu, kao što su mehanizmi za
identifikaciju i autentifikaciju, ureĊaji za fiziĉku kontrolu pristupa (video
nadzor, protivprovalni senzori i sl.), kriptografski mehanizmi, neki
IDS/IPS i.t.d., nego i na raspoloţivu dokumentaciju zaštite (zakone,
standarde, uputstva i.t.d.), kao i fiziĉko kretanje ljudi kroz raĉunski centar
i njihove operativne i upravljaĉke aktivnosti.

Kontrole zaštite poseduju dva osnovna atributa: robusnost (otpornost na

napade) i adaptivnost (fleksibilnost i skalabilnost), [10].
Robusnost kontrole zaštite omogućava definisanje kontrola sa razliĉitom
jaĉinom bezbednosne funkcije i bezbednosne garancije, u zavisnosti od
efikasnosti implementacije. Kontrole zaštite aplicirane u IKT sistem
mogu se zasnivati na:
 mehanizmima i protokolima zaštite (mehanizmi identifikacije i
autentifikacije, ureĊaji za fiziĉku kontrolu pristupa, kriptografski
mehanizmi, zaštitni protokoli), ili
 dokumentima zaštite (zakoni, standardi, program, politike, plan i
procedure zaštite, sporazumi, ugovori).

- 197 -
Robusnost kontrole zaštite odreĊena je sa dva kljuĉna faktora:

 jačinom bezbednosne funkcije pridruţene kontroli, koja se odreĊuje

kao relativna mera potrebnih napora ili troškova za proboj korektno
implementirane kontrole, i
 nivoom bezbednosne garancije (asasurance) ili osnove za sticanje
poverenja u efikasnost/efektivnost kontrole, koji se odreĊuje kao
funkcija korišćene metodologije za projektovanje kontrole zaštite,
snage i dizajna kontrole i konteksta u kojem se kontrola koristi.

Za potrebe metrike implementacije kontrola zaštite, definisana su tri

nivoa robusnosti kontrole zaštite: osnovni, poboljšani (srednji) i jaki
(visoki).

Adaptivnost (skalabilnost i fleksibilnost) kontrole zaštite omogućava

organizaciji da izabere kontrole zaštite koje najviše odgovaraju i
zadovoljavaju definisane politike zaštite i potrebe organizacije, kao i da
se kontrole mogu poboljšavati. Fleksibilnost kontrole odnosi se na
fleksibilnu primenu poznatih formi zaštite (n.p.r. bekapovanje sedmiĉno,
meseĉno i.t.d.).

- 198 -
2.2. Struktura, organizacija i identifikacija kontrola zaštite

Struktura kontrole zaštite ima standardnu formu iz više razloga.

Postoje brojni tipovi razliĉitih kontrola zaštite koje se mogu iskoristiti u
konkretnom sistemu zaštite. Kontrole zaštite se dinamiĉki razvijaju i
menjaju u zavisnosti od promena u sistemu upravljanja, operativnim
uslovima rada sistema i tehnologijama zaštite. Da bi se obezbedilo
efikasno i automatizovano upravljanje rizikom, odnosno sistemom
zaštite, prvi korak je izrada kataloga (baze podataka) kontrola zaštite. U
opštem sluĉaju, struktura kontrola zaštite u katalogu treba da sadrţi tri
sekcije:

1. cilja (osnovna, poboljšana, jaka zaštita),

2. opisa (specifiĉni zahtevi i detalji za osnovnu, poboljšanu i jaku
zaštitu) i
3. mapiranja (zahteva za zaštitu da bi se izbeglo nepotrebno
dupliranje kontrola).

Organizacija kontrola zaštite u katalogu obezbeĊuje njihovu lakšu

primenu. Kontrole zaštite se organizuju hijerarhijski u: klase, familije i
kontrole.
Jednoznačna identifikacija kontrola zaštite obezbeĊuje jedinstveno
kodiranje svake kontrole u katalogu primenom standardizovane
konvencije:

- klase: numeriĉki (1, 2, 3),

- familije: sa dva velika slova koja jednoznaĉno definišu ime
familije,
- nivoa robusnosti kontrola zaštite: sa o-osnovna robusnost, p-
poboljšana robusnost i j -jaka robusnost i
- broj kontrole: koji se stavlja ispred ovog identifikatora, a
odreĊuje redosled kontrole u okviru familije prema prioritetu
bezbednosnog znaĉaja.

Primer: VD-4.o jedinstveno oznaĉava: ĉetvrtu kontrolu zaštite u familiji

planiranja vanrednih dogaĊaja sa osnovnim nivoom robusnosti.
Postoje tri opšte klase kontrola zaštite: Upravljačke, Operativne i
Tehničke. Svaka klasa kontrola zaštite sadrţi familije kontrola zaštite, a
familije sadrţe konkretne kontrole zaštite iz neke od klasa.

- 199 -
2.2.1. Upravljačke kontrole zaštite

Upravljaĉke kontrole zaštite tipiĉno ukljuĉuju dokumentovane mere

zaštite, koje se odnose na upravljanje sistemom zaštite i rizikom. Klasa
upravljaĉkih kontrola sadrţi 5 familija kontrola zaštite za:

1. Procena (upravljanje) rizika,

2. Planiranje zaštite,
3. Akvizicija sistema i servisa zaštite,
4. Analiza (revizija) kontrola zaštite i
5. Sertifikacija i akreditacija sistema zaštite.

- 200 -
2.2.2. Operativne kontrole zaštite

Operativne kontrole podržavaju upravljaĉke i tehniĉke kontrole

zaštite. Za razliku od tehniĉkih kontrola koje primarno izvršava IKT
sistem, operativne kontrole tipiĉno izvršavaju ljudi koji podrţavaju
sistem. Klasa operativnih kontrola sadrţi 9 familija kontrola zaštite koje
obezbeĊuju:

1. Personalnu zaštitu,
2. Fiziĉku zaštitu i zaštitu okruţenja,
3. Upravljanje vanrednim dogaĊajima,
4. Upravljanje konfiguracijom sistema,
5. Odrţavanje hardvera i softvera sistema,
6. Odrţavanje integriteta sistema i informacija,
7. Zaštitu medija,
8. Upravljanje kompjuterskim incidentom i
9. Razvoj svesti o potrebi zaštite i obuku.

2.2.3. Tehničke kontrole zaštite

Tehniĉke kontrole su mere zaštite, tipiĉno opisivane kao mehanizmi i

protokoli zaštite koji se koriste unutar hardvera, softvera ili memorijskih
ĉipova IKT sistema za zaštitu sistema i informacija u njemu od
neovlašćenog pristupa, otkrivanja, modifikacije ili uništavanja. Klasa
tehniĉkih kontrola sadrţi 4 familije kontrola zaštite koje obezbeĊuju:

1. Identifikaciju i autentifikaciju,
2. Logiĉku kontrolu pristupa,
3. Kontrolisanu odgovornost (eng. accountability), ukljuĉujući i
nadzor i kontrolu i
4. Zaštitu sistema i komunikacija.

U tabeli T. 2.1 navedeni su zbirno klase, pripadajuće familije i

jedinstveni identifikatori familija za srpsku i (englesku) konvenciju
kodiranja.

- 201 -
 Klasa Familija Identifikator
Procena rizika PR (RA)
Planiranje zaštite PZ (PL)
1. Upravljaĉka Akvizicija sistema i servisa AS (SA)
Analiza kontrola zaštite, AK (CR)
Sertifikaciju i akreditaciju sistema zaštite AP (PA)
Zaštita personala ZP (PS)
Fiziĉka zaštita i zaštita od okruţenja FZ (PE)
Planiranje i rad u vanrednim dogaĊajima VD (CP)
Upravljanje konfiguracijom sistema UK (CM)
2. Operativna Odrţavanje hardvera i softvera OD (MA)
Integritet sistema i informacija IN (SI)
Zaštita medija ZM (MP)
Odgovor na incidente OI (IR)
Obuka u zaštiti i podizanje svesti o potrebi OB (AT)
Identifikacija i autentifikacija IA (IA)
Logiĉka kontrola pristupa LP (AC)
3. Tehniĉka Kontrolisana odgovornost PO (AU)
(Accountability) i kontrola (Audit)
Zaštita sistema i komunikacija ZK (SP)

T. 2.1. Jedinstvena identifikacija kontrola zaštite

- 202 -
3. SISTEM KONTROLA ZA OSNOVNU ZAŠTITU

U razvoju i realizaciji programa zaštite, zadatak organizacije je da

odredi odgovarajući skup kontrola zaštite koje će, kada se implementiraju
i verifikuju u primeni, biti usklaĊene sa planom zaštite i zahtevima za
kontrolama zaštite. Izbor adekvatnih kontrola zaštite za ispunjavanje
specifiĉnih i ponekad jedinstvenih zahteva za zaštitu neke organizacije,
vaţan je zadatak jer demonstrira stvarnu odluĉnost organizacije u zaštiti
poverljivosti, integriteta i raspoloţivosti objekata IKT sistema, [4].

Sistem kontrola za osnovnu zaštitu (eng. Baseline security) je minimalan

skup kontrola koje se preporuĉuju za neki IKT sistem i koje obezbeĊuju
odrţavanje ukupnog preostalog rizika na prihvatljivom nivou. Potrebne i
rentabilne kontrole zaštite odreĊuju se i biraju na bazi bezbednosne
kategorizacije i klasifikacije objekata IKT sistema i procene rizika. Svaka
modifikacija sistema kontrola za osnovnu zaštitu mora se dokumentovati.

Za efikasno upravljanje sistemom zaštite, treba izraditi kompletan

katalog kontrola zaštite definisanih u ovom trenutku u bazama znanja i
koristiti ga kao radni dokument zaštite. U takvom katalogu kontrola
zaštite identifikuju se tri osnovna skupa upravljačkih, operativnih i
tehničkih kontrola koje odgovaraju niskom, srednjem i visokom nivou
zaštite, definisanom u procesu kategorizacije i klasifikacije. Lista
osnovnih kontrola daje se respektivno za svaku od tri osnovna skupa
kontrola, koje obezbeĊuju minimum kontrola zaštite za odgovarajuću
bezbednosnu kategoriju IS.

Kontrole zaštite u svakoj od tri osnovna skupa kontrola sadrţi

kombinaciju kontrola od tri nivoa robusnosti iz kataloga kontrola zaštite.
Na primer, za niski nivo osnovne zaštite sadrţi kontrole zaštite sa
osnovnim nivoom robusnosti; za srednji nivo osnovne zaštite –
kombinaciju kontrola zaštite sa osnovnim i poboljšanim nivoima
robusnosti; za visoki nivo osnovne zaštite - kombinacija kontrola zaštite
sa osnovnim, poboljšanim i jakim nivoima robusnosti. Ne postoji
direktna korelacija izmeĊu tri nivoa robusnosti kontrola zaštite i tri nivoa
osnovnih skupova kontrola zaštite. Odgovarajuće kontrole zaštite biraju
se za odgovarajuće nivoe osnovne zaštite. Na primer, neka kontrola
zaštite sa osnovnim nivoom robusnosti moţe se prvo pojaviti na
visokom nivou osnovnog sistema zaštite, ili se ta kontrola moţda nikada
ne pojavljuje u bilo kojem osnovnom sistemu kontrola zaštite i samo je

- 203 -
na raspolaganju kao opcija organizaciji za dopunu skupa kontrola. Neke
kontrole zaštite mogu se primenjivati u sva tri osnovna skupa kontrola
zaštite i za sve nivoe robusnosti. Takve kontrole se nazivaju
kompenzujuće (univerzalne) kontrole zaštite.

Osnovni skup kontrola zaštite namenjen je da obezbedi pokrivanje

odreĊenih potencijalnih pretnji. Zbirna i uporedna tabela osnovnih
skupova kontrola zaštite pomaţe u razumevanju zahteva za relativno
povećanje robusnosti kontrola zaštite. Na primer: Skup kontrola
osnovne zaštite za niski uticaj faktora pretnji sadrţi ukupno 158 kontrola
zaštite sa niskim nivoom robusnosti: 29 upravljaĉkih, 60 operativnih i 39
tehniĉkih kontrola zaštite.

Pridruţivanje specifiĉnim zahtevima za zaštitu odgovarajućih kontrola

zaštite, definisanih u katalogu kontrola zaštite, vrši se pomoću
odgovarajuće matrice za praćenja bezbednosnih zahteva – RTM (eng.
Requirements Traceability Matrix). Treba poĉeti sa specifiĉnim
bezbednosnim zahtevima za koje mora postojati usaglašenost. Svaki
zahtev za zaštitu mapira se prema odgovarajućoj kontroli zaštite unutar
izabranih osnovnih skupova kontrola zaštite. Mapiranje zahteva za
zaštitu prema kontrolama zaštite moţe biti:

 1:1 (jedan prema jedan) – jedan zahtev rešava se sa jednom

kontrolom zaštite,
 1:N (jedan prema više) – jedan zahtev rešava se sa više kontrola
zaštite,
 N:1 (više prema jedan) - više zahteva rešava se sa jednom kontrolom
zaštite i
 N:1 (više prema više) - više zahteva rešava se sa više kontrola zaštite.

U tabeli T. 3.1. ilustrovan je primer dela MPZ matrice za hipotetiĉke

zahteve za zaštitom i standardizovan skup kontrola zaštite u katalogu
kontrola zaštite.

- 204 -
 Zahtevi zaštite Mapiranje Kontrole zaštite
Zahtev br. 1 1 :1 PS-1b
Zahtev br. 2 1 :N PE-2b, PE-3b, PE- 6e, PE-7b
Zahtev br. 3
N:1 CM-2e
Zahtev br. 4
Zahtev br. 5
N:N IA-1e, IA-2e, IA-4b
Zahtev br. 6

T.3.1. Primer matrice praćenja zahteva za zaštitom

Kontrole zaštite koje popunjavaju familije zaštite nisu statiĉke kategorije

i mogu se vremenom revidirati i dopunjavati na osnovu: prakse zaštite i
iskustva iz korišćenja kontrola, promena u zahtevima zaštite u
organizaciji i pojave novih tehnologija zaštite. Neke kontrole se
eliminišu, a druge dodaju. Predlog dodavanja, brisanja ili modifikacije
kontrola zaštite mora proći rigoroznu javnu raspravu, reviziju i
konsenzus svih zainteresovanih strana u organizaciji. Katalog kontrola
zaštite uvek treba da sadrţi i odrţava dinamiĉan, fleksibilan i tehniĉki
konzistentan skup kontrola zaštite.

- 205 -
4. PROCES SELEKCIJE KONTROLA ZAŠTITE

Poverenje u IS moţe se steći sa paţljivom selekcijom i

implementacijom, na odgovarajući naĉin definisanog i kreiranog
osnovnog skupa kontrola zaštite. Proces selekcije odgovarajućih kontrola
zaštite za neki sistem, idealno treba da bude završen u toku rane faze
ţivotnog ciklusa razvoja sistema (pre usaglašavanja) i da se vrši na bazi
analize rizika. Aktivnosti u ovoj fazi primene koncepta kontrola zaštite
su, [4]:

 izbor inicijalnog skupa kontrola osnovne zaštite,

 kreiranje skupa kontrola osnovne zaštite prema zahtevima zaštite
(mapiranje) i
 dokumentovanje konaĉnog skupa kontrola osnovne zaštite u Planu
zaštite.

4.1. Izbor osnovnih kontrola zaštite

1. korak: KATEGORIZACIJA I KLASIFIKACIJA OBJEKATA IKT

SISTEMA

Iz Plana zaštite treba uzeti sledeće informacije koje se odnose na

sistem, [1], [3]:

 granice akreditacije za sistem i ako je pogodno predloţenu

dekompoziciju sistema,
 kritiĉnost/osetljivost sistema/podsistema na bazi bezbednosnih
zahteva,
 izloţenost sistema napadima spolja i iznutra, na osnovu bezbednosnih
zahteva.

U izboru skupa kontrola osnovne zaštite prvi korak je uspostavljanje

bezbednosnih kategorija i klasifikacije objekata IKT sistema. Proces
kategorizacije tesno je povezan sa procesom klasifikacije objekata. Moţe
se reći da se procesom klasifikacije objekti svrstavaju u klase ili
kategorije objekata na koje se mogu primeniti svi atributi klasifikacije.
Standardni proces kategorizacije uspostavlja bezbednosne kategorije za
informacije i za objekte IKT sistema. Informacije se svrstavaju u
kategorije u odnosu na tip informacije, [8]. Tip informacije je specifiĉna
kategorija informacija (kao što su privatna, zdravstvena, intelektualna

- 206 -
svojina, finansijska, nauĉno-istraţivaĉka, vojna, osetljiva poslovna,
diplomatska, obaveštajna, upravljanje zaštitom i.t.d.), koju definiše neka
organizacija, posebni zakon, izvršna uredba vlade, predsedniĉki ukaz,
politika ili druge regulative. Bezbednosne kategorije se zasnivaju na
potencijalnom uticaju faktora rizika na: misiju organizacije, zaštitu
imovine, funkcionalnost, ispunjavanje preuzetih obaveza i zaštitu prava
zaposlenih. Bezbednosne kategorije definišu se u odnosu na ranjivosti
sistema i pretnje u procesu procene rizika za IS i organizaciju u celini, za
tri bezbednosna cilja, [1]: zaštitu poverljivosti (P) , zaštitu integriteta (I),
zaštitu raspoloživosti (R).

Potencijalni uticaj na organizaciju i pojedince realizuje neki agent

pretnje probojem sistema zaštite, tj. kada doĊe do gubljenja (P), (I) i (R)
objekata IKT sistema. Kvalitativna mera uticaja faktora rizika na objekte
IKT sistema moţe biti: nizak, srednji, visok.

Klasifikacija bilo kojih objekata mora da ima sledeće atribute, [6]:

7. MeĎusobnu isključivost – spreĉava preklapanja, klasifikacija u

jednu kategoriju iskljuĉuje sve ostale kategorije koje su
meĊusobno disjunktne;
8. Potpunost – unija svih kategorija obuhvata sve moguće
klasifikacije;
9. Nedvosmislenost – svaka klasifikacija mora biti jasna i precizna;
10. Ponovljivost – svaki proces klasifikacije mora biti ponovljiv i da
daje isti rezultat;
11. Prihvatljivost – svaka klasifikacija mora biti logiĉka i intuitivna;
12. Promenljivost – klasifikacija mora biti primenljiva u razliĉitim
sferama istraţivanja.

U kontekstu sistema zaštite pod kategorizacijom podrazumeva se

klasifikacija svih objekata IKT sistema u bezbednosne kategorije na koje
se mogu primeniti svi navedeni atributi klasifikacije, dok se pojam
klasifikacije odnosi na klasifikaciju bezbednosnih nivoa informacija
(primer klasifikacije informacija: interne, poverljive, strogo poverljive,
državna tajna).

Bezbednosnu kategoriju tipa informacije odreĊuje potencijalni uticaj

gubitka (P), (I) i (R) koji ima najveću vrednost od svih potencijalnih
uticaja odreĊenih za taj tip informacija.

- 207 -
Bezbednosna kategorizacija IS zahteva neznatno više analize i mora
razmatrati bezbednosne kategorije svih tipova informacija i objekata koji
postoje u IS. Bezbednosnu kategoriju IS odreĊuje potencijalni uticaj od
gubitka (P), (I) i (R) koji ima najveću vrednost od svih potencijalnih
uticaja odreĊenih za svaki tip informacije i objekta u IS, tj. uzima se za
najgori slučaj uticaja faktora rizika.

Klasifikacija informacija nije krut proces, baziran je na analizi

rentabiliteta, a vrši se u odnosu na: zahteve za zaštitu (P, R i I), kategoriju
informacija, status kategorije informacija i značaj informacija.

Opšti metod za izraţavanje bezbednosnih kategorija – BK objekata

nekog IS je, [1]:

BK= (uticaj na P), (uticaj na I), (uticaj na R)= uticajmax,

gde se prihvatljiva vrednost potencijalnog uticaja pretnji uobiĉajeno

rangirana kao: N- nizak, S - srednji i V - visok uticaj.

Ka bezbednosna kategorija registruje se najveća vrednost od

potencijalnih uticaja pretnji na izabrane atribute objekata IKT sistema,
koja nosi najveći rizik.

Primer: Neka je u odreĊivanju bezbednosne kategorije procesa akvizicije

IKT opreme-BKao organizacije procenjen sa S uticajem pretnji na (P) i
(I) i N uticajem na (R), biće: BKao=(P, S), (I, S), (R, N) = uticajmax =S

2. korak: IZBOR MINIMUMA KONTROLA ZAŠTITE ZA DATI IKT

SISTEM
 izabrati minimum kontrola zaštite iz kataloga kontrola za sistem
osnovne zaštite,
 izabrati minimum dodatnih kontrola zaštite, za srednji ili viši nivo
zaštite, na osnovu povećanja bezbednosnih zahteva.

Na bazi najveće vrednosti potencijalnog uticaja pretnji, iz kataloga

osnovnih kontrola zaštite izabere se inicijalni skup kontrola za sistem
osnovne zaštite, koji se po potrebi moţe uvećavati sa dodatnim
kontrolama, što znaĉi ako je najveći potencijalni uticaj:
 N, izaberu se osnovne kontrole zaštite za niski uticaj pretnji,

- 208 -
 S, izaberu se osnovne kontrole zaštite za srednji (i niski) uticaj
pretnji, i
 V, izaberu se osnovne kontrole zaštite za visoki (srednji i niski) uticaj
pretnji.

Kako je u gornjem primeru maksimalna vrednost potencijalnog uticaja -

srednji, biraju se osnovne kontrole zaštite za srednji nivo uticaja pretnji.

3. korak: PRILAGOĐENJE REZULTATIMA PROCENE RIZIKA

U ovom koraku treba:

 na bazi procene rizika prilagoditi izabrani skup minimalnih kontrola
zaštite i
 opisati i dokumentovati povuĉene, zamenjene, modifikovane i nove
kontrole.

- 209 -
4.2. Kreiranje skupa kontrola osnovne zaštite

Posle izbora inicijalnog skupa kontrola osnovne zaštite, mogu se

kreirati kontrole koje ispunjavaju specifiĉne potrebe IKT sistema, kroz
dve aktivnosti:

 prilagoĊavanje skupa kontrola osnovne zaštite rezultatima analize

rizika,
 pridruţivanje definisanih vrednosti objekata IKT sistema (N,S,V)
kontrolama zaštite, gde postoje indicije na osnovu operativnih
zadataka i operacija IKT sistema.

Procena rizika igra vaţnu ulogu u procesu selekcije kontrola zaštite.

Pokrivanje procenjenih pretnji skupom kontrola osnovne zaštite treba
razmatrati na bazi analize rizika da bi se donele odluke za, [8]:

 dodavanje novih kontrola zaštite radi smanjenja ili eliminacije

ranjivosti sistema na pretnje koje nisu pokrivene inicijalnim skupom
kontrola osnovne zaštite (iz kataloga),
 izbacivanje odreĊenih kontrola zaštite, ili ne uvoĊenje novih kontrola,
na osnovu procene da je verovatnoća iskoristivosti poznatih ranjivosti
dovoljno niska, ili
 zamenu, ili poboljšanje preporuĉene kontrole zaštite.

Postoje odreĊene kontrole zaštite u katalogu kontrola koje treba formirati

prema specifiĉnim potrebama organizacije, što se u katalogu indicira sa
italik tekstom kao: (zadatak:... ) i specifiĉnim vrednostima objekata
definisanim od strane organizacije za eksplicitno identifikovane
parametre – kao: (selekcija). Promenljivi delovi ovog tipa kontrola zaštite
(zadatak i selekcija) popunjava svaka organizacija tako da reflektuju
specifiĉne zahteve konkretnog IKT sistema i rezultate analize rizika. Ovo
je konaĉan korak u procesu formiranja skupa kontrola zaštite, adekvatnog
za konkretan sistem i okruţenje.

U primerima u PRILOGU I 10B ilustrovane su operacije ukljuĉivanja

zadataka i selekcije na tri familije kontrola zaštite iz klasa upravljaĉkih,
operativnih i tehniĉkih kontrola, uzetih iz kataloga kontrola.

- 210 -
4.3. Osnovne aktivnosti za implementaciju kontrola zaštite

Opšte je prihvaćeno da su analiza rizika i odgovarajuća analiza

bezbednosnih zahteva za rentabilnim kontrolama zaštite, primarni faktori
svakog programa zaštite. Tehniĉki sistem zaštite u IKT nije dovoljan sam
po sebi, nego deluje kao interaktivni skup politika zaštite, definisanih na
opšte prihvaćenim normativima i standardima zaštite i odgovarajućih
operativnih uputstava, dokumenata zaštite, mehanizama i protokola
zaštite, projektovanih tako da podrţavaju procese rada organizacije,
sliĉno ostalim internim upravljaĉkim kontrolama organizacije.

Kontrole zaštite (upravljačke, operativne i tehničke) identifikuju se i

implementiraju tako da obuhvataju specifiĉne faktore rizika za procese
rada. Svaka kontrola zaštite ima svoju cenu, pa zato proces
implementacija kontrola mora ukljuĉivati trţišne rezone. Opšte je
prihvaćeno da je procena faktora rizika u IKT sistemu, u smislu njihovog
uticaja na procese rada organizacije, bitan korak za izbor i odreĊivanje
vrste kontrola, koje treba implementirati i koliki nivo resursa se moţe
utrošiti na te kontrole. Otuda je razumevanje uticaja faktora rizika na
procese rada organizacije, u kontekstu sistema bezbednosti i zaštite,
početna tačka ciklusa upravljanja rizikom i sistemom zaštite.

Kako postoji više metoda za procenu efektivnosti kontrola zaštite,

razvijena je Vežba GI P10A sa ciljem da se studenti nauĉe da prepoznaju
uslove u kojima odreĊeni metod za procenu efektivnosti kontrola zaštite
daje najbolje rezultate i ima najveću vrednost.

- 211 -
4.4. Dokumentovanje kontrola zaštite u planu zaštite

Rezultati izbora skupa kontrola zaštite i procesa specifikacije

dokumentuju se u Plan zaštite, koji prolazi kroz razliĉite faze razvoja, ali
na kraju obuhvata sve kontrole zaštite, planirane, ili već
implementirane.Vaţno je da konaĉni skup kontrola zaštite, izabranih ili
identifikovanih u IKT sistemu, bude dokumentovan u Planu zaštite sa
svim obrazloţenjima i glavnim razlozima (eng. racionals) za konaĉni
izbor kontrola zaštite, sa indikatorima koji ukazuju na prateću
dokumentaciju i koji objašnjavaju zašto izabrane kontrole zaštite
ispunjavaju bezbednosne zahteve organizacije. Plan zaštite predstavlja
osnovu za sertifikaciju i akreditaciju sistema zaštite, a rezultati
sertifikacije i akreditacije su presudni za donošenje odluke o povezivanju
IKT sistema sa drugim sistemima izvan domena zaštite (i granice
akreditacije), na naĉin koji odrţava stepen zaštite na prihvatljivom nivou
rizika..

- 212 -
5. KATALOG KONTROLA OSNOVNE ZAŠTITE
5.1. Sistem kontrola osnovne zaštite
Sistem kontrola osnovne zaštite obezbeĊuje minimalni nivo
zaštite i poĉetnu poziciju svake organizacije u proceni stvarnog skupa
kontrola zaštite, potrebnog za zaštitu sistema. Sistem kontrola osnovne
zaštite povezan je sa inicijalnom bezbednosnom kategorizacijom
objekata IKT sistema i pokriva procenjeni skup pretnji. Organizacija
treba da izvrši analizu rizika u poĉetnoj fazi razvoja ţivotnog ciklusa
sistema da bi kreirala odgovarajuće kontrole zaštite za sistem osnovne
zaštite.
Kontrole osnovne zaštite za nizak nivo uticaja pretnji sadrţe dve kljuĉne
komponente: sekciju bezbednosnih ciljeva (svih ciljeva odreĊene
kontrole primenjene u sistemu) i sekciju opisa kontrole (specifiĉnih
zahteve i detalja svake kontrole), a obuhvata sledeće familije:
1. Familija: Procena rizika PR (RA)
2. Familija: Planiranje zaštite PZ (PL)
3. Familija: Akvizicija sistema i servisa AS (SA)
4. Familija: Revizija kontrola zaštite AK (CR)
5. Familija: Autorizacija procesiranja AP (PA)
6. Familija: Personalna zaštita ZP (PS)
7. Familija: Fiziĉka zaštita i zaštita okruţenja FZ (PE)
8. Familija: Planiranje vanrednih dogaĊaja VD (CP)
9. Familija: Upravljanje konfiguracijom UK (CM)
10. Familija: Odrţavanje hardvera i softvera OD (MA)
11. Familija: Integritet sistema i informacija IN (SI)
12. Familija: Zaštita medija ZM (MP)
13. Familija: Upravljanje incidentima OI (IR)
14. Familija: Obuka i razvoj svesti o potrebi OB (AT)
15. Familija: Identifikacija i autentifikacija (IA) (IA)
16. Familija: Logiĉka kontrola pristupa LP(AC)
17. Familija: Kontrolisana odgovornost, ukljuĉujući kontrolu tragova PO
(AU)
18. Familija: Zaštita sistema i komunikacija ZK(SP)
Primeri kontrola osnovne zaštite za nizak uticaj pretnji i poboljšane
kontrole za srednji uticaj pretnji dati su u PRILOGU I 10C. Katalog
kontrola osnovne zaštite za niski nivo uticaja pretnji dat je u celini u
literaturi, [11].

- 213 -
6. REZIME

Ciljevi definisanja kontrola zaštite je da se izrade katalozi

kontrola zaštite (radna dokumenta i pomoćni alat u procesu projektovanja
sistema zaštite), obezbede osnovni elementi za Plan zaštite i Uputstva
zaštite i olakša izbor adekvatnih (rentabilnih, optimalnih) kontrola
sistema zaštite, na osnovu procesa analize rizika.

Kontrola zaštite, krajnja klasifikacija mehanizama zaštite, tipiĉno je neka

funkcija dizajna sistema i ne odnosi se samo na tehniĉke mehanizme
zaštite, kao što su mehanizmi za identifikaciju i autentifikaciju, ureĊaji za
fiziĉku kontrolu pristupa, kriptografski mehanizmi i.t.d., nego i na
raspoloţivu dokumentaciju zaštite (zakone, standarde, uputstva i.t.d.),
kao i fiziĉko kretanje ljudi kroz raĉunski centar i njihove operativne i
upravljaĉke aktivnosti.

Kontrole zaštite poseduju dva osnovna atributa: robusnost (otpornost na

napade) i adaptivnost (fleksibilnost, skalabilnost). Robusnost kontrole
definiše stepen jaĉine bezbednosne funkcije i bezbednosne garancije
zaštite, u zavisnosti od efikasnosti implementacije. Adaptivnost
(skalabilnost i fleksibilnost) kontrole zaštite definiše mogućnost
proširivanja (nadgradnje) skupa kontrola zaštite i mogućnost izbora
kontrola zaštite koje najviše odgovaraju i zadovoljavaju definisane
politike zaštite i potrebe organizacije. Fleksibilnost kontrole odnosi se na
mogućnost izbora poznatih mera zaštite, n.p.r., bekapovanje sa
obaveznim rokovima: sedmiĉno, meseĉno i.t.d..

U katalogu kontrola zaštite, kontrole se organizuju u klase (upravljačkih,

operativnih i tehničkih) kontrola i familije, koje sadrţe konkretne
kontrole zaštite u okviru neke klase.

Klasa Upravljačkih kontrola zaštite sadrţi 5 familija kontrola zaštite, a

ukljuĉuje dokumentovane, administrativne mere zaštite koje se odnose na
upravljanje sistemom zaštite i rizikom, akviziciju sistema i servisa,
analizu kontrola zaštite i sertifikaciju akreditaciju.

Klasa Operativnih kontrola zaštite podrţava upravljaĉke i tehniĉke

kontrole zaštite IKT sistema. Za razliku od tehniĉkih kontrola koje
primarno izvršava IKT sistem, operativne kontrole tipiĉno izvršavaju
ljudi koji odrţavaju sistem, a sadrţi 9 familija kontrola zaštite koje

- 214 -
obezbeĊuju: personalnu zaštitu, fiziĉku zaštitu i zaštitu okruţenja,
planiranje rada u vanrednim dogaĊajima, upravljanje konfiguracijom
sistema, odrţavanje hardvera i softvera sistema, integritet sistema i
informacija, zaštitu medija, upravljanje kompjuterskim incidentom,
razvoj svesti o potrebi zaštite i obuku.

Klasa Tehničkih kontrola zaštite, tipiĉno opisivana kao mehanizmi i

protokoli zaštite, obuhvata hardversko-softverske kontrole koje štite
sistem i informacije u njemu od neovlašćenog pristupa, korišćenja,
otkrivanja, modifikacije ili uništavanja. Ova klasa sadrţi 4 familije
kontrola zaštite koje obezbeĊuju: identifikaciju i autentifikaciju, logiĉku
kontrolu pristupa, kontrolisanu odgovornost (ukljuĉujući i za kontrolu i
nadzor) i zaštitu sistema i komunikacija.

U realizaciji programa zaštite, zadatak organizacije je da definiše

odgovarajući skup kontrola osnovne zaštite, implementira ga i verifikuje
usklaĊenost sa Planom zaštite i bezbednosnim zahtevima. Izbor pravih
kontrola zaštite za ispunjavanje specifiĉnih i ĉesto jedinstvenih zahteva
za zaštitu neke organizacije, vaţan je zadatak jer demonstrira stvarnu
odluĉnost organizacije u zaštiti poverljivosti, integriteta i raspoloţivosti
objekata IKT sistema.

Sistem kontrola osnovne zaštite je minimalnih skup kontrola, koje se

preporuĉuju za osnovni nivo zaštite nekog IKT sistema, sa ciljem
odrţavanja ukupnog preostalog rizika na prihvatljivom nivou. Potrebne i
rentabilne kontrole zaštite odreĊuju se i biraju na bazi bezbednosne
kategorizacije i klasifikacije objekata IKT sistema i procesa analize
rizika. Svaka modifikacija osnovnih kontrola mora se dokumentovati u
Planu zaštite.

Za potrebe efikasnog upravljanja sistemom zaštite, treba koristiti

(izraditi) katalog svih kontrola zaštite (Upravljaĉkih, Operativnih i
Tehniĉkih) za sva tri nivoa pretnji (Niski, Srednji, Visoki), preporuĉenih
standardima najbolje prakse. Iz kataloga kontrola zaštite identifikuju se
tri skupa osnovnih kontrola koje odgovaraju N, S i V nivou zaštite,
definisanom u procesu kategorizacije i klasifikacije, na osnovu N, S i V
nivoa uticaja pretnji. Lista osnovnih kontrola zaštite daje se respektivno
za svaki od tri skupa osnovnih kontrola (U,O,T za N, S i V nivoe zaštite),
koje obezbeĊuju minimum kontrola zaštite za odgovarajuću bezbednosnu
kategoriju IKT sistema.

- 215 -
Sistem osnovnih kontrola zaštite za N uticaj pretnji sadrţi ukupno 158
kontrola zaštite sa niskim (n) nivoom robusnosti: 29 upravljaĉkih, 60
operativnih i 39 tehniĉkih kontrola zaštite.

- 216 -
7. KLJUĈNI TERMINI

Fleksibilnost kontrole zaštite: omogućava izbor kontrola zaštite koje

najviše odgovaraju i zadovoljavaju definisane politike zaštite i potrebe
organizacije.
Kontrola zaštite: konaĉna (krajnja) klasifikacija mehanizama zaštite,
tipiĉno neka funkcija arhitekture sistema zaštite, a odnosi se na tehniĉke
sisteme, operativne i upravljaĉke aktivnosti.
Operativne kontrole zaštite: organizovane u 9 familija ukljuĉuju
organizacione i tehniĉke kontrole zaštite IKT sistema, kojima upravljaju
ljudi: personalnu zaštitu, fiziĉku zaštitu i zaštitu okruţenja, plan rada za
vanredni dogaĊaj, upravljanje konfiguracijom sistema, odrţavanje
hardvera i softvera sistema, integritet sistema i informacija, zaštita
medija, upravljanje kompjuterskim incidentom i razvoj svesti o potrebi
zaštite i obuku.
Robusnost kontrole zaštite: omogućava definisanje kontrole sa
razliĉitom jaĉinom bezbednosne funkcije (funkcije zaštite) u zavisnosti
od efikasnosti implementacije.
Struktura kontrola zaštite: ĉine je klase (upravljaĉke, operativne,
tehniĉke), koje sadrţe familije, koje obuhvataju kontrole (upravljaĉke,
operativne, tehniĉke).
Tehniĉke kontrole zaštite: organizovane u 4 familija ukljuĉuju
mehanizme zaštite, koji se koriste unutar hardvera, softvera ili
memorijskih ĉipova IKT sistema, a obezbeĊuju identifikaciju i
autentifikaciju, logiĉku kontrolu pristupa, kontrolisanu odgovornost
(ukljuĉujući i za auditing-kontrolu i nadzor) i zaštitu sistema i
komunikacija
Upravljaĉke kontrole zaštite: organizovane u 5 familija ukljuĉuju
dokumentovane mere zaštite, koje se odnose na upravljanje sistemom
zaštite, procenom rizika, planiranjem zaštite, akvizicijom IKT sistema i
servisa, analizom kontrola zaštite i akreditacijom i sertifikacijom.

- 217 -
8. LITERATURA:

1. Barker William C., Guide for Mapping Types of Information and

Information Systems to Security Categories, NIST SP800-60 -1 i
2, http://www.csrc.nist.gov/publications, juni 2004.
2. Barker William C., Guideline for Identifying an Information
System as a National Security System, NIST SP SP 800-59,
http://www.csrc.nist.gov/publications, 2003.
3. FIPS 199–FISMA (Federal Information Security Management
Act of 2002-PublicLaw107-347),
http://www.itl.nist.gov/l/fipspubs, decembra 2003.
4. FIPS Publication 200, Minimum Security Requirements for
Federal Information and Information Systems,
http://www.itl.nist.gov/l/fipspubs, juni 2005.
5. Grubor G., Katalog kontrola sistema osnovne zaštite za nizak
uticaj pretnji, skripta, Univerzitet SINGIDUNUM - FPI, maj
2006.
6. Howard D. J., An analizis of Security Incedent 1989/1995,
Doctor‘s Thesis, Carnegie Mellon University. 1997.
7. ISO/IEC 17799:2000, Information Technology – Code of practice
for information security management, http://www.iso.17799.org,
2003.
8. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
9. NIST SP 800-12, An Introduction to Computer Security: The
NIST Handbook, http://www.csrc.nist.gov/publications, 2004.
10. Ross R., Swanson M., &all, Guide for the Security Certification
and Accreditation of Federal Information Systems, NIST SP 800-
37, http://www.csrc.nist.gov/publications, 2004.
11. Ross R., Katzke S., NIST SP 800-53, A, B, C, Recommended
Security Controls for Federal IS,
http://www.csrc.nist.gov/publications, 2005.

- 218 -
 II GLAVA
RAZVOJ PROGRAMA ZAŠTITE INFORMACIONIH
SISTEMA

- 219 -
1. PRETNJE I RIZICI ZA INFORMACIONE SISTEME

0. UVOD

Po završetku ovog poglavlja razumećete:

- značaj taksonomija pretnji

- osnovne tipove malicioznih napada (virusi, crvi, trojanci,...)
- mere zaštite i oporavka sistema od malicioznih napada

Odrţavanje stanja bezbednosti IS na prihvatljivom nivou rizika,

podrazumeva neprekidno praćenje i što preciznije identifikovanje
potencijalnih pretnji i faktora rizika od kojih treba štititi objekte IS.
Faktori rizika odreĊuju se u procesu analize rizika i definišu od čega se
informacije i IS moraju štititi.

Uporedo sa razvojem i umreţavanjem poverljivih RM u sistem globalne

mreţe - Internet, rastu i potencijalne pretnje od razliĉitih napada sa
Interneta, ukljuĉujući brojne maliciozne programe, socijalni inţenjering i
druge napade hakera, krakera, vandala i kompjuterskih terorista.
Raĉunarske mreţe Internet tipa nude brojne prednosti i omogućavaju
izuzetno povećanje efikasnosti rada i smanjenje troškova, ali
predstavljaju i kritiĉnu taĉku bezbednosti, sa stanovišta rizika za
raspoloţivost, integritet i poverljivost informacija. Iako su ranije napadi
na RM Internet tipa bili preteţno eksterni, novije analize pokazuju da
mnogo veće finansijske gubitke i drugu štetu nanose interni napadi.
Razlozi su u samoj prirodi mreţa Internet tipa u sistemu e-poslovanja u
kojima interni uĉesnici nisu samo zaposleni u organizaciji (za koje
postoji odreĊeni stepen poverenja), već i poslovni partneri, zaposleni u
firmama podruţnicama, kooperanti, dostavljaĉi, itd., koji iz razloga
jednostavnosti korišćenja i povećanja efikasnosti i produktivnosti rada
imaju vrlo sliĉan, ako ne i isti, pristup RM organizacije kao i interno
zaposleni.

Pored finansijske dobiti brojni su motivi za razne vrste hakerskih i drugih

napada na RM drţavnih organa, meĊu kojima su najĉešće: izazov i
potreba za samopotvrĊivanjem, znatiţelja, maliciozne namere - kraĊa
osetljivih informacija, špijunaţa i namerna oštećenja informacija,
aplikacija i sistema.

- 220 -
Mogući naĉini odbrane od navedenih napada su: antivirusna zaštita na
više nivoa, šifrovanje, procedure jake autentifikacije i korišćenje smart
kartica za generisanje digitalnog potpisa i bezbedno ĉuvanje kljuĉeva i
drugih kriptografskih parametara, primena tehnologije digitalnog
sertifikata i potpisa, korišćenje jakih kljuĉeva i ĉesta izmena kljuĉeva,
zaštita adresa servera i dr.. Najbolje rezultate daju kombinovani sistemi
bazi analize rizika.

- 221 -
1. PRETNJE I NAPADI

1.1. Taksonomije pretnji i napada

Moguće su brojne taksonomije (principi klasifikacije na bazi

definisanih kriterijuma) agenata pretnji u odnosu na razliĉite kriterijume.
Krajnji cilj svake taksonomije pretnji je da se specijalistima zaštite i
korisnicima obezbedi lakše definisanje i identifikovanje različitih tipova,
najčešće kombinovanih, dinamički promenljivih pretnji za IS.

Taksonomija izvora pretnji, prema prirodi izvora, deli pretnje na

slučajne-Sl i namerne-Na. U tom smislu pod sluĉajnim pretnjama u ovoj
taksonomiji podrazumevaju se nenamerne ljudske greške u radu, otkazi
hardvera i softvera, prirodni vanredni dogaĊaji i.t.d., koje se ne smatraju
namernim napadima na sistem, ali su ozbiljni uzroci bezbednosnih
incidenata. Za formalnu analizu rizika od interesa je procena svih pretnji
koje izazivaju bezbednosne incidente. Namerne pretnje generišu ljudi, a
rezultat su namerni (najĉešće zlonamerni) napadi.

Taksonomija tipa pretnji na osnovu gornje podele izvora pretnji, ĉesto

korišćena u formalnoj analizu rizika, je klasifikacija u 6 sledećih
kategorija, [6], [12]:

1. Maliciozne zloupotrebe ranjivosti IKT sistema: planirane su i

realne, ako je sistem prikljuĉen na Internet; ĉesto sa probnim
skeniranjem ranjivosti sistema;
2. Maliciozni kompjuterski kriminal: kraĊa, destrukcija, korupcija,
incidenti izazvani izvana ili iznutra,
3. Nebriga: personala, ne sprovoĊenje procedura, korišćenje preĉica
i.t.d. Ove su pretnje istinska opasnost za organizacije.
4. Ljudska greška: sluĉajne, glavni su izvori bezbednosnih incidenata i
ozbiljan signal za dodatnu obuku i reviziju procedura.
5. Pad sistema: iznenadan pad sistema i odbijanje izvršavanja servisa
(DoS) moţe imati katastrofalne posledice za sam IS i poslovni
sistem, koji se oslanja na njega.
6. Uticaj okruženja: uticaj vanrednih dogaĊaja; jedini naĉin
suprostavljanja je izrada i verifikacija Plana za vanredne dogaĎaje i
kontinuitet poslovanja.

- 222 -
U tabeli T.1.1. prikazani su primeri tipa pretnje, objekata napada i tipova
incidenata.

Tip pretnje Ugroţeni objekat Tip incidenta

Spisak kupaca, Projekat Ukraden spisak kupaca, kraĊa
Zloupotrebe
proizvoda projektne dokumentacije i plana
Virus uništio podatke na
Kompjuterski kriminal Projekat proizvoda
umreţenom PC
Finansijski izveštaji modifikovani
Nebriga Izveštaj organizacije
neovlašćenim pristupom korisnika
Detalji projekta novog proizvoda
Ljudska greška Projekat proizvoda greškom dati konkurentskoj
organizaciji
Spisak kupaca i Primarni aplikacioni server nije
Pad sistema
izveštaji organizacije spreĉio pristup nalozima klijenata
Sve elektronske Oluja i kiša izazvale poplavu
Okruţenje
informacije centra IS i uništen server

T. 1.1. Primeri ugroţenih objekata i tipova incidenata za odreĊene

tipove pretnji

Realna pretnja prisutna, realizovana u IS naziva se napad. Napad moţe

biti uspešan ili neuspešan, zavisno od jaĉine napada i otpornosti sistema
zaštite.

Taksonomija kombinovanih napada prihvatljiva je za kvalitativnu

analizu rizika u odnosu na sledeća tri kriterijuma: posledica uticaja:
štetan-Št, neškodljiv-Nš, izvor nastanka: iznutra-Un, spolja-Va i način
izvoĎenja: sofisticiran – So, nesofisticiran – Ns, [20].

U praksi zaštite ove tri klase napada najĉešće se realizuju u kombinaciji,

proizvodeći uticaje na hardver, programe, servise i podatke kroz 8
razliĉitih kombinacija napada:

(ŠtSoUn, ŠtSoVa, ŠtNsUn, ŠtNsVa, NšSoUn, NšSoVa, NšNsUn,

NšNsVa).

Praktična, redukovana taksonomija izvora pretnji na bazi opisa

kljuĉnih karakteristika pretnji za IS, a za potrebe izbora upravljaĉkih,
operativnih i tehniĉkih kontrola zaštite, koje efikasno i efektivno
„pokrivaju― te pretnje, klasifikuje izvore pretnji na: greške, prirodne

- 223 -
dogaĎaje i namerne napade. Greške izazvane ljudima ili mašinama,
mogu uticati na IS na razne naĉine, od minimalnih degradacija
performansi do kompletnog gubitka servisa sistema. Prirodni dogaĎaji
mogu izazvati oštećenja ili uništenje sistema, zavisno od intenziteta i
obima napada. Namerni napadi obiĉno su, mada ne uvek, voĊeni
malicioznim namerama napadaĉa, sa promenljivim stepenom intenziteta i
mogu biti izvor potencijalnih oštećenja sistema, operacija ili objekata
organizacije. Namerni napadi obiĉno se karakterišu prema sledećim
atributima: tipu, sposobnostima napadača, resursima napadača (oprema,
motivacija i prilika) i namerama napadača. U tabeli T.1.2 date su zbirne
karakteristike atributa namernih napada, [5].

- 224 -
 TIP NAPADA
Lokalni zahteva se fiziĉko prisustvo napadaĉa na mestu napada i razmeštaja IS
ne zahteva se fiziĉko prisustvo napadaĉa na mestu napada i razmeštaja IS
Mreţni
napadaĉ inicira napad sa mreţe.
SPOSOBNOST NAPADAĈA
Napadaĉ ima uobiĉajene sposobnosti za rad sa IS, ograniĉeno znanje o IS
Niska
kojeg napada i ne koristi posebne alate za napad.
Napadaĉ ima jednu/obe sposobnosti: (i). Koristi sofisticirane alate za napad
Visoka (ukljuĉujući javno raspoloţive alate), i/ili (ii). Napadaĉ koristi napredne
IKT tehnike za napad.
PRISTUP IS
napadaĉ nije korisnik IS, nije privilegovan korisnik IS ili je privilegovan
Iznutra
korisnik IS.
Izvana napadaĉ je legalan ili nije (nelegalan) korisnik IS ili je javni korisnik IS.
NAMERA NAPADAĈA
napadaĉ nema nameru da ošteti IS, ili da nanese štetu organizaciji nego
Nemaliciozan
izvodi napade zbog znatiţelje, dosade ili intelektualnog izazova.
napadaĉ ima jasnu nameru da ošteti IS, ili izazove štetu organizaciji koja
Maliciozan
negativno utiĉe nas poslove organizacije i njene resurse.
RESURSI NAPADAĈA
napadaĉ je: (i) samoinicijativan i samo-motivisan; (ii) radi nezavisno (kao
Minimalni pojedinac ili u maloj grupi), bez spoljnog uticaja, usmeravanja ili voĊenja i
(iii) izvršava napad sa minimalnim raĉunarskim resursima.
napadaĉ je: (i) deo grupe/organizacije, koja ne ukljuĉuje organizacije koje
se bave komercijalnom špijunaţom, kriminalom ili terorizmom); (ii) radi sa
Srednji znaĉajnim usmeravanjem/voĊenjem od strane rukovodstva grupe ili
organizacije i pod uticajem je grupe ili organizacije i (iii) izvršava napad sa
proseĉnim resursima.
napadaĉ je: (i) deo grupe ili organizacije koja ukljuĉuje organizacije koje se
bave obaveštajnim radom, informacionim ratovanjem ili drţavno-
sponzorisanim terorizmom); (ii) radi sa znaĉajnim usmeravanjem i
Znaĉajni
voĊenjem od strane rukovodstva grupe ili organizacije i direktno je pod
upravom grupe ili organizacije i (iii) izvršava napad sa znaĉajnim
resursima.

Tabela 1.2. Zbirne karakteristike atributa namernih napada

Kljuĉni tipovi napada mogu se svrstati u sledeće grupe napada hakera,

krakera, vandala i kompjuterskih kriminalaca: destrukcije, izmena
podataka, prekid servisa (DoS napad), špijunaža i neovlašćen korišćenje.

Kompjuterski kriminalac je tipiĉno mlad, inteligentan, uzoran i

odgovoran radnik na poslu, spreman na prekovremeni rad, visoko
motivisan i istraţivaĉki orijentisan. Ima razvijeno logiĉko mišljenje,
dobro poznaje i koristi raĉunarski sistem. Potencijalno je savršen
kompjuterski kriminalac, samo mu treba jak motiv, da: postane pohlepan,
razvije ne-prijateljski odnos sa nekim iz uprave organizacije, postane
osvetoljubiv i sl.

- 225 -
Za zloupotrebe i kompjuterski kriminal potrebni su motiv, sredstvo i
prilika. U istrazi i dokazivanju svakog kriminala istraţni organ nastoji da
sazna zašto? (motiv), kako? (sredstvo) i kada? (priliku) i da ih logiĉki
poveţe u ĉvrsti dokaz kriminalnog dela, [20].

Opšti motivi hakera su znatiţelja, novac, moć, osveta (nezadovoljni

zaposleni i drugi. Pored opštih motiva, hakersku populaciju karakterišu
posebni motivi, od kojih su presudni: intelektualni izazov, radoznalost i
avanturistiĉki duh, zabava, potreba za trijumfom, opijenost sopstvenim
znanjem i veštinama, kompenzacija osećaja manje vrednosti, osećaj
elitizma, pritisak hakerske organizacije, prestiţ i dr., [26].

Sredstva ĉine tehnološki kapaciteti sa kojima hakeri izvršavaju kriminal i

nivo veštine koju napadaĉ poseduje. Prilika za izvršavanje
kompjuterskog kriminala ili zloupotrebe je iskorišćena ranjivost i najteţe
se odreĊuje zbog mogućnosti postavljanja raznih vrsta zamki
(vremenskih tempiranih logiĉkih bombi, virusa, Trojanaca i.t.d.) za
uklanjanje tragova napada.

Hakeri se prema kriterijumu namere koju imaju kada hakerišu tuĊe

raĉunarske sisteme mogu podeliti na: kreativce, destruktivce i kriminalce,
[26].

- 226 -
1.2. Pregled procena gubitaka i vrsta napada

Prema podacima ameriĉkog National Institute for Standards and

Technologies (NIST) iz 2003. godine, oko 99% svih registrovanih upada
u IKT sistem rezultat su korišćenja poznatih ranjivosti operativnih
sistema (OS) ili grešaka konfiguracije, za koje su bile na raspolaganju
mere zaštite. Jedan od brojnih pregleda i analiza pretnji za korišćenje RM
u Internet okruţenju [10], ukazuje na tipove napada, u procentima
prijavljenih napada Sl. 1.1) i proseĉne gubitke prouzrokovane tim
napadima u 2001. (a) i 2005. (b) godini u SAD (Sl.1.2).

Prema jednom sliĉnom pregledu ameriĉkog instituta za zaštitu raĉunara

(Computer Security Institute-CSI, 2000 Computer Crime and Security
Survey) koji je obuhvatao velike korporacije, 70% razmatranih subjekata
je prijavilo detektovane neautorizovane pristupe u svojim mreţama u
prethodnoj godini. TakoĊe, prema istoj analizi, u prethodnih 5 godina, 66
razmatranih subjekata je prijavilo ukupan gubitak proizveden kraĊom
osetljivih korporacijskih informacija u iznosu od $66 708 000, a 54
razmatrana subjekta su prijavila ukupan gubitak proizveden finansijskom
proneverom u iznosu od $53 996 000, [20].

Sl. 1.1. Tipovi prijavljenih napada na raĉunarske mreţe u

procentima

- 227 -
 a).

b). [FBI. 2005, Computer Crime Survay]

Sl. 1.2. Proseĉni gubici u 2001. (a) i 2005. godini (b)

Obe analize potvrĊuju sledeće trendove u korišćenju raĉunarskih mreţa

Internet tipa, [20]:

 razvoj sve šireg spektra mogućih napada, porast finansijskih i drugih

gubitaka zbog napada na raĉunarske mreţe Internet tipa.
 primena samo komercijalnih tehnologija zaštite informacija ne
predstavlja pouzdano rešenje odbrane od potencijalnih napada, već se
mora koncipirati i primeniti slojevita i sveobuhvatna zaštita koja,
pored komercijalne tehnologije zaštite obavezno ukljuĉuje i primenu
sopstveno realizovanih mehanizama zaštite (kriptoloških, kontrole

- 228 -
 pristupa), kao i proceduralne (upravljaĉke i organizacione) kontrole
zaštite.

Tipiĉni napadi malicioznih programa virusnog tipa u toku dana imaju

propagaciju, [29], (Sl. 1.3):

– oblika zvonaste krive,

– sa maksimalnim intenzitetom u toku dana (oko 10 ĉasova) i
– sa opadanjem širenja kada je većina hostova inficirano i kada je
teško naći neinficiran host.

Sl. 1.3. Dnevna propagacija virusa, [29]

Na osnovu istraţivanja SANS Instituta (SAD) definisane su tri liste

osnovnih grešaka koje omogućavaju razliĉite vrste napada na mreţe i
radne stanice u mreţi Internet tipa.

Prva lista krajnjih korisnika definiše sledećih pet najvećih bezbednosnih

grešaka:

 otvaranje nezahtevanog priloga e-pošte (attachment) iz nepoverljivog

izvora,
 neredovno instaliranje bezbednosnih popravki (patches-zakrpe) iz
standardnih Internet programskih paketa, kao i novih definicija
(upgrade) antivirusnih programa,
 instaliranje i preuzimanje (download) programa za zaštitu ekrana
(screen savers) i igara iz nepoverljivih izvora,
 nekreiranje rezervnih kopija programa i netestiranje ovih operacija i
 korišćenje modema sa raĉunara vezanog u lokalnoj raĉunarskoj mreţi
(LAN).

- 229 -
Druga lista menadžerske strukture definiše sledećih sedam najvećih
bezbednosnih grešaka koje utiĉu na stvaranje ranjivosti raĉunarske mreţe
organizacije, [20]:

 neobezbeĊenje odgovarajućeg broja specijalista za uspostavljanje i

odrţavanje sistema zaštite u IS organizacije,
 primena samo organizacionih vidova zaštite bez primene (i bez
prihvatanja neophodnosti primene) tehniĉkih mehanizama zaštite
informacija,
 rešavanje samo pojedinaĉnih bezbednosnih problema bez primene
mera i stvaranja uslova za kreiranje kompletnog sistema zaštite koji
bi osigurao rešenje najšireg spektra bezbednosnih problema,
 korišćenje samo mreţnih barijera (firewalls) u korporacijskoj
raĉunarskoj mreţi,
 neshvatanje koliko vrede intelektualno vlasništvo i poslovna
reputacija firme,
 primena kratkotrajnih rešenja pojedinaĉnih situacija što dovodi do
brzog umnoţavanja bezbednosnih problema i
 iluzija da će se bezbednosni problemi rešiti sami od sebe ako se
ignorišu.

Treća lista informatičkih profesionalaca definiše sledećih deset najvećih

bezbednosnih grešaka, [20]:

 prikljuĉivanje RS na Internet bez prethodne primene neophodnih

bezbednosnih mera,
 prikljuĉivanje test i razvojnih sistema na Internet sa default
lozinkama,
 neredovno aţuriranje sistema sa rešenjima nekih bezbednosnih
problema,
 korišćenje nebezbednih protokola za upravljanje sistemima, ruterima,
barijerama i PKI infrastrukturom,
 davanje korisnicima lozinki preko telefona i njihovo menjanje bez
prethodne autentifikacije osobe koja zahteva izmenu,
 propust pri odrţavanju i testiranju procedure snimanja rezervnih
kopija sistemskih programa,
 korišćenje nepotrebnih Internet servisa,
 neprecizno konfigurisanje i primena mreţnih barijera koje ne
obezbeĊuju osetljivi dolazeći i odlazeći saobraćaj,

- 230 -
 neredovno aţuriranje ili neimplementacija antivirusnih programa i
 slaba edukacija korisnika o potencijalnim bezbednosnim problema.

Imajući u vidu navedene tipiĉne greške, najĉešći tipovi potencijalnih

napada na savremene raĉunarske mreţe Internet/Intranet tipa su, [20]:

 virusni napadi, uništavanje podataka;

 napad ukidanja servisa (DoS-Denial-of-Service), onemogućavanje
funkcionisanja mreţnih servisa i resursa, [9];
 ponavljanje poslatih poruka (spam), neovlašćena kontrola
komunikacije subjekata i ponavljanje, izmena ili spreĉavanje prenosa
podataka;
 pogaĎanje lozinke, neovlašćeni pristup podacima uz pomoć
otkrivene lozinke, [11], [13];
 napadi tipa Trojanskog konja, distribucija zlonamernih programa na
radne stanice;
 lažno predstavljanje, (društveni inţenjering) neautorizovani pristup
podacima ili kreiranje neautorizovanih podataka, [18], [19];
 prisluškivanje, neovlašćeno pristupanje podacima u otvorenom
obliku i lozinkama,
 kriptoanaliza, otkrivanje tajnih kljuĉeva, otkrivanje podataka u
otvorenom obliku na bazi šifrata i otkrivenog tajnog kljuĉa, [20];
 napadi skeniranjem, identifikovanje potencijalnih objekata napada i
lociranje ranjivih mesta: topologije mreţe, vrste prenosa koji prolazi
kroz mreţnu barijeru, aktivne matiĉne raĉunare u RM, aktivne OS,
vrste ureĊaja za povezivanje u RM, aktivne aplikacije, brojeve verzija
programa i nivoe popravki, informacije o nalogu. Poznati napadi
skeniranjem su: ARP (protokol za razrešavanje adresa) skeniranje,
ICMP (protokol o greškama u poruci) skeniranje [4], UDP (protokol
za korisniĉke datagrame) skeniranje i TCP skeniranje (povezivanja,
SYN skeniranje poluotvorene TCP konekcije [7], segment FIN,
XMAS, NULL, ACK i fragmentacija), [8]. Dobar pregled tehnika
skeniranja i posledica dat je u literaturi [1];
 otimanje sesije, uglavnom od klijenta i komunikacija sa serverom bez
autentifikacije, [21];
 zloupotreba softvera, najĉešće prekoraĉenjem bafera, skriptovanje
preko web lokacije i dr., [22].

- 231 -
Iako pomenuti napadi nisu specifiĉni samo za TCP/IP raĉunarske mreţe
oni su tu najviše ispoljeni, jer se daleko najveći broj RM u svetu bazira
na Internet tehnologijama.

- 232 -
2. PREGLED MALICIOZNIH PROGRAMA

Maliciozni program je kôd koji se tajno ubacuje u drugi program sa

namerom da se unište podaci, pokrenu destruktivni programi ili na drugi
naĉin kompromituje bezbednost i naruši poverljivost, integritet ili
raspoloţivost informacija. UvoĊenje malicioznih kôdova u IKT sistem
smatra se najznaĉajnijom pretnjom za sistem. Granice izmeĊu raznih
malicioznih kodova postaju sve slabije: logiĉka bomba (zadnja vrata),
zamka, Trojanac, virusi, crvi i mobilni programi (malware). Internet je
preplavljen malicioznim kôdovima. Najopasnija je sprega laţnih (hoaxes)
virusa i Trojanaca, jer ne inficira sistem, vremenski je uporna, teško se
otklanja i moţe omogućiti distribuciju virusa i Trojanaca.

Posledice uticaja infekcije malicioznim kôdovima za IKT sistem mogu

biti razliĉite: preplavljivanje sistema (spam), obaranje sistema, brisanje,
kraĊa i transfer podataka i.t.d. Maliciozni kôdovi mogu uticati na jedan,
ili sve bezbednosne aspekte zaštite: tajnosti, integriteta i raspoloţivosti, a
najĉešće se dele u pet sledećih kategorija, [12]: virusi, Trojanci, crvi,
mobilni kôdovi i kombinovani napadi.

Virusom, crvom i "Trojancem" sistem se moţe zaraziti na više naĉina,

preko: disketa, USB, narezanog CD, DVD i sl.; datoteka koje stiţu u
prilogu e-mail poruke; datoteka koje se skidaju sa Interneta; web lokacije
na kojoj je postavljen virus ili skript koji generiše viruse ili Trojance;
iskorišćavanja ranjivosti sistema u samim programima i OS, ĉime se
omogućava penetracija virusa, Trojanca ili crva.

- 233 -
2.1. Virusi

Definicije i generatori virusa postoji veliki broj, od kojih je teško

izdvojiti najbolju. Najĉešće se koristi prva i najviše usvajana definicija
[27], po kojoj je „Kompjuterski virus program koji ˝inficira˝ ostale
programe, modifikujući ih tako da uključuju njegovu naprednu kopiju. Sa
inficiranog područja, virus se može širiti kroz kompjuterski sistem i
mrežu, koristeći autorizaciju svakog korisnika da inficira njihove
programe. Svaki program koji se inficira, takoĎe se ponaša kao virus pa
se infekcija povećava―. Prema [6] „Računarski virus je segment
mašinskog kôda, obično od 200-4000 bajta, koji će nakon aktiviranja
kopirati svoj kôd na jedan ili više programa domaćina. Prilikom
izvršavanja programa domaćina, „zaraženi― kôd će biti izvršen i virus će
nastaviti da se širi―.

Kompjuterski virus je dizajniran da se replicira, pravi svoje kopije i

distribuira ih u druge datoteke, programe ili raĉunare. Iskljuĉivi cilj
virusa je da naprave štetu na zaraţenom kompjuteru. Šire se uglavnom
tako što se "ugnezde" u druge datoteke, a zatim brišu ili menjaju datoteke
na disku. U sluĉaju da se radi o RM, virus iz zaraţenog raĉunara moţe da
potraţi drugi raĉunar u mreţi, da bi na njemu izmenio ili oštetio datoteke.

Virus generišu gotovo iskljuĉivo tehniĉki virtuozi [6]. Postoji nekoliko

mogućih uzroka pojave virusa: malicoznost napadača, komercijalni
razlog (proizvoĊaĉi softvera lansiraju viruse da spreĉe pirateriju) i
hakersko ratovanje (kao oblik informatiĉkog ratovanja).

Generalno, ne postoje maliciozni i benigni virusi, pošto i ovi poslednji

zauzimaju resurse raĉunara pa, iako nisu štetni, mogu se menjati i time
omogućiti neţeljene radnje.

U principu, kao prenosilac virusa moţe posluţiti bilo koji program, ali je
to najĉešće zajedniĉki program za više aplikacija, kojeg koristi veliki
broj korisnika. Neki virusi napadaju samo odreĊene programe, dok drugi
napadaju širok spektar programa. Najĉešći prenosioci virusa su: Boot
sektor, Master boot zapis; izvršne datoteke (npr., .COM i .EXE
ekstenzija) i datoteke koje sadrţe izvršni kôd (npr. Word i Excel
dokumenta koja sadrţe samoizvršavajuće makroe).

- 234 -
TakoĊe, moguće je napraviti viruse koji inficiraju drajvove. Virusi koji
napadaju boot sektor, verovatno su se prvi pojavili, jednostavni su za
kreiranje, relativno dobro su sakriveni (ako ne prikazuju poruke na
ekranu), ali se lako odstranjuju iz sistema.Virusi koji inficiraju izvršne
datoteke pojavili su se ubrzo za njima, a danas postoje višedelni virusi
koji inficiraju i programske datoteke i boot sektore. Neki od virusa imaju
sposobnost premeštanja izmeĊu boot sektora i programa. Ovo ih ĉini
teţim za analizu, jer je nemoguće napraviti test datoteke bez inficiranja
hard diska.

Programski virusi koji koriste DOS-ove funkcije, da bi bili rezidentni

smeštaju se na niţe memorijske lokacije, dok ostali programi koriste
memoriju iznad njih. Virus koji modifikuje memorijski alokacioni lanac
obiĉno sebe pomera na vrh nominalne memorije, a pokazivaĉ vrha
pomera naniţe. Virusi koji inficiraju boot sektor obiĉno zauzimaju vrh
memorije. Neki virusi se smeštaju na vrh memorije, ali pri tom ne
rezervišu taj prostor da bi se zaštitili. Oni ne mogu biti otkriveni
postupkom provere koliĉine slobodne memorije, ali većina velikih
programa srušiće sistem kad se prepišu preko virusa. OdreĊeni virus
traga za slobodnom memorijom u sistemskoj zoni, a mnogi programi
koriste ovu zonu i vrlo je verovatno da će ovaj tip virusa srušiti većinu
sistema.

Taksonomije virusa su brojne, broj virusa u stalnom porastu, a ĉesta

klasifikacija je na, [20]:

Virusi BOOT sektora, koji se „kaĉe― uz program master boot record

(MBR), u boot sektoru ĉvrstog diska (HD), ili boot sektoru prenosnog
medija. Boot sektor je zona na poĉetku drajva ili diska, gde su
uskladištene informacije o strukturi drajva/diska. Oni sadrţe boot
programe koji se sami pokreću kod startovanja hosta da aktiviraju
operativni sistem. MBR na HD je jedinstvena lokacija na disku gde su
smešteni osnovni ulazno/izlazni sistem (BIOS) raĉunara i boot program.
Prenosni mediji kao što je flopi disketa ne treba da se butuje da bi
inficirala sistem; ako je inficiran disk u drajvu kada se kompjuter butira
virus se moţe aktivirati. Ovi virusi su najnezgodniji, jer se nalaze u
najdubljem delu OS. Samim tim mogu preuzeti kontrolu i nadgledati
apsolutno svaku operaciju na raĉunaru. Nakon ukljuĉenja, prvi se
aktiviraju, pre bilo kojeg dela OS. Jedini naĉin detekcije i uklanjanja ovih
virusa je reinstalacija OS sa originalnog (ĉistog) butabilnog CD-a, koji je

- 235 -
zaštićen od snimanja, uz paralelnu upotrebu antivirusnog programa. Kad
se jednom otkriju, ovi se virusi vrlo lako uklanjaju. Klasiĉni primeri ovih
virusa su Michelangelo i Stoned.

Virusi komandnog procesora sliĉni su prethodnim, osim što se uĉitavaju

malo kasnije u procesu podizanja OS. Njihova moć nad OS je samim tim
smanjena. Kada se otkriju, lako se uništavaju.

Univerzalni virusi (virusi infektori datoteka) su najraširenija kategorija

virusa. Uglavnom se lepe za odreĊene tipove datoteka i nemaju veze sa
sistemskim delom OS. Najĉešći cilj su im .EXE i .COM datoteke. Nakon
uĉitavanja prvog zaraţenog programa, sele se u memoriju i ĉekaju svaki
naredni izvršni program da bi ga zarazili. Drugi metod ispoljavanja ovih
virusa ukljuĉuje viruse koji modifikuju naĉin na koji raĉunar otvara neku
datoteku, umesto modifikovanja aktuelnog programa koji aktivira
datoteku. U ovom scenariju aktivira se prvi virus, a onda program.
Glavna strategija nastupa ovih virusa je, da od izvršne datoteke naprave
Trojanskog konja. Najpoznatiji virusi iz ove kategorije su Jerusalem i
Cascade.

Složeni virusi su veoma opasni jer kombinuju tehnike rasprostiranja,

razmnoţavanja i ugroţavanja, pa su vrlo fleksibilni. Vrhunac su
tehnologije programiranja virusa.

Usmereni virusi su strogo namenski programi za uništenje odreĊenog

broja taĉno odreĊenih tipova datoteka.

Makrovirusi, preovlaĊujući i najuspešniji tipovi virusa, u suštini su

programi napisani u makro jezicima. Za sada najĉešći su makrovirusi za
Microsoft Word, Excel i Microsoft Office, Microsoft Access baze i dr. U
ovim sistemima virusi preuzimaju kontrolu kada se otvori ili zatvori
virusom inficirana datoteka. Makrovirusi se sami zakaĉe za dokument, a
koriste makro programski jezik neke aplikacije za izvršavanje i
propagaciju. Ima tendenciju brzog širenja, jer korisnici ĉesto koriste
aplikacije sa makro funkcijom. Prvo zahvataju standardne funkcije
programa, a onda inficiraju svaku narednu datoteku koja se otvori. Znaju
oštetiti i sam sadrţaj datoteke. Najpoznatiji makrovirusi su Concept,
Marker i Melissa.

- 236 -
Lažni virusi daju laţna upozorenja virusnog napada, sa alarmantnim
upozorenjem da je raĉunar napadnut razornim virusom i da se zahteva
trenutna akcija za adekvatnu zaštitu raĉunara. Ĉesti su koliko i stvarni
virusi. Obiĉno izazivaju neznatne štete, ali troše operativno vreme. Neki
maliciozni laţni virusi mogu usmeriti korisnika da izmeni podešavanje
OS ili izbriše datoteke, što moţe izazvati bezbednosni problem. Dobri
primeri ovih virusa su Good Times i Bud Frogs.

Mehanizam širenja virusa obezbeĊuju i podstiĉu savremene raĉunarske

mreţe i umreţavanje. Pre pojave umreţavanja raĉunara virusi su imali
mnogo manje šanse da se šire (jedino da neko donese zaraţen flopy disk
ili nešto sliĉno). Pojavom umreţavanja raĉunara u mreţe tipa
Internet/Intranet, koje se baziraju na nebezbednim TCP/IP protokolima,
virusi se mogu širiti neverovatnom brzinom i na mnogo sofisticiranije
naĉine. Vaţno je uoĉiti da su se virusi pojavili i da apsolutne zaštite od
novih i nepoznatih virusa nema. Najveći problem predstavlja sam OS
koji je uglavnom nebezbedan, bez obzira na tip.

Preterana agresivnost virusa u nastojanju da se proširi, moţe izazvati

sumnju korisnika zbog povećane aktivnosti procesora. S druge strane,
ako je nastup virusa isuviše diskretan, neće uspeti da inficira veći broj
datoteka. Tako su izdiferencirane dve glavne klase mehanizma infekcije
virusom, [20]:

 Direktni infektori: kod izvršavanja inficiranog programa, virus

aktivno traga za datotekom ili datotekama, koje će zaraziti. Pri tom,
moţe se pretraţivati tekući drajv ili direktorijum, ili selektovani
direktorijumi, kao što su oni navedeni u PATH iskazu. Zatim, se
uĉitava i izvršava inficirana datoteka; ne ostaju u memoriji i nisu
univerzalni, jer mehanizam inficiranja nije preterano efikasan, a
oĉigledna je dodatna aktivnost diska, posebno kada su sve datoteke
zaraţene.
 Indirektni infektori: pri pokretanju programa inficiranog virusom,
virus se smešta u memoriju, obiĉno preusmerava jedan ili više
interaptova i potom izvršava originalni program. Većina ovakvih
virusa inficira svaku datoteku, koja je uĉitana radi izvršavanja, dok
neki inficiraju svaku izvršnu datoteku, koja je uĉitana, bez obzira na
razlog uĉitavanja.

- 237 -
Sa aspekta efikasnosti virusa, postoji podela na brze i spore infektore:

 Brzi infektori inficiraju ne samo datoteke koje se izvršavaju, nego i

one kojima se pristupa iz bilo kojeg razloga; koriste ĉak i antivirusne
programe koji ne otkrivaju njegovo prisustvo u memoriji, da zarazi
datoteke koje oni otvaraju zbog provere na virus.
 Spori infektori inficiraju samo datoteke koje su u fazi kreiranja ili
modifikovanja i tako zaobilaze programe za kontrolu integriteta
sistema.

Neki virusi sakrivaju svoj kôd, ili ĉak inficiranu datoteku, šifrovanjem.
Jedini tekst koji se moţe videti unutar inficirane datoteke je procedura
dešifrovanja. Virusi su najĉešće šifrovani nekom jedinstvenom
procedurom, kao što je XOR-ovanje svakog bajta sluĉajno izabranim
kljuĉem, za svaku novu kopiju. Detekcija ovih virusa zasniva se na
pronalaţenju procedure za dešifrovanje na poĉetku virusnog koda.

Štetne posledice virusa menjaju se iz godine u godinu i od jedne do

druge statistiĉke analize, zavisno od dinamiĉkih promena intenziteta
generisanja i napada novih virusa i drugih malicioznih programa. U

- 238 -
Tabeli 1.1 ilustrovane su štetne posledice napada virusima na poslovni
sistem neke organizacije, na bazi višegodišnjih statistiĉkih analiza, [2],
[20].

Gubitak produktivnosti
62%
Smetnje
41%
Uništene datoteke
32%
Izgubljeni podaci
30%
Nepoverljive aplikacije
24%
Pad sistema (DoS)
23%
Gubitak poverenja
20%
Oštećen E-mail
9%
Opasnost gubitka posla
3%

T. 1.1. Štetne posledice virusa

Tipovi virusa su bezbrojni, a ĉesto se pominju: virusi rezidentni u

memoriji koji se ne gase, kada se jednom pokrenu u memoriji; višedelni
virusi koji inficiraju više od jedne kategorije objekata; retro virusi koji
uzvraćaju, namerno pokušavaju da zaobiĊu operacije specifiĉne za
antivirusne programe; stelt virusi razvijeni da izbegnu antivirusni
program; tunel virusi koji izbegavaju antivirusne programe, smeštaju se
u memoriji i blokiraju normalan rad i dr.

- 239 -
2.2. Trojanci

Trojanac je prosta forma malicioznog programa, ĉija je spoljna

manifestacija obiĉno zabavna i interesantna proseĉnim korisnicima, a
najĉešće prikazuje poruke, briše datoteke ili diskove i ne inficira ostale
izvršne datoteke, jer se ne umnoţava (replicira). Trojanci nisu virusi zato
što se ne umnoţavaju, već stoje i ĉekaju da budu pokrenuti, direktnim
aktiviranjem, ili uz pomoć drugog programa koji ga pozove. Posledice
ubaĉenih Trojanaca mogu biti katastrofalne - ko ubaci Trojanca u
raĉunarski sistem moţe uništiti sva dokumenta na disku, prebaciti ih na
svoj raĉunar, potrošiti Internet-vreme korisnika, ili iskoristiti raĉunar za
napad na neki server, što se pripisuje vlasniku sistema.

Trojanci se najĉešće ubacuju direktnim unosom sa raĉunara neovlašćenog

korisnika preko prenosnog medija, ili indirektnim putem, preko Interneta
slanjem e-mail poruke koja sadrţi datoteku (igru, sliku i sl.) koja je u
stvari Trojanac, sa instrukcijom kojom se korisnik moli da startuje
dobijeni program. Ovo vaţi uopšte za sve programe koji sluţe za
komunikaciju preko Interneta.

Trojanci se ĉesto teško detektuju, jer naizgled izvršavaju korisne

funkcije, a ispoljavaju se u jednom od tri sledeća modela, [20]:

1. Nastavljajući da izvršavaju funkciju originalnog programa,

dodatno izvršavaju odvojene maliciozne aktivnosti;
2. Nastavljajući da izvršavaju funkciju originalnog programa,
modifikuju funkciju da bi izvršili malicioznu aktivnost (npr.
verzija Trojanca kao login programa koji skuplja lozinke), ili da
maskira druge maliciozne aktivnosti (npr., verzija Trojanaca kao
programa za listiranje procesa koji ne prikazuje maliciozne
programe), ili
3. Izvršavajući maliciozne funkcije koje kompletno zamenjuju
funkcije operativnog programa.

Cilj većine Trojanaca je da omogući udaljenom korisniku pristup i punu

kontrolu nad napadnutim raĉunarom. Da bi ovo postigao Trojanac se
sastoji od klijentske i serverske komponente. Klijentska komponenta se
nalazi na udaljenom raĉunaru napadaĉa i traţi da uspostavi vezu sa
serverskom komponentom, koja se nalazi na napadnutom host raĉunaru.
Kada je uspostavljena veze izmeĊu klijentske i serverske komponente,

- 240 -
udaljeni napadaĉ moţe izvršavati komande na napadnutom raĉunaru i
preneti ili modifikovati podatke. Druga uobiĉajena namena Trojanaca je
da deluju kao agenti distribuiranih DoS napada. Drugi Trojanci ne
obezbeĊuju udaljeni pristup raĉunaru ţrtve. Većina Trojanaca postoji
jednostavno da prikrije dokaz o kompjuterskom incidentu, kao što je
potiskivanje imena malicioznih procesa sa liste procesa. Neki Trojanci
skupljaju informacije kao što su pasvordi; drugi su konfigurisani da
dnevno šalju liste lozinki e-poštom na poseban e-mail nalog.

Vremenske bombe su sliĉne Trojancima, sliĉno su programirane i imaju

mogućnost da unište podatke. One su napravljene sa ugraĊenim
vremenskim tempiranim ―trigerom‖ koji se aktivira u odreĊeno vreme i
napravi neko neţeljeno dejstvo na raĉunaru.

2.3. Crvi (Worms)

Crvi su takoĊe programi koji menjaju ili uništavaju podatke. To su

programi koji mogu da šire svoje kopije, ili njihove delove na druge RS,
obiĉno preko mreţa. Neki ih smatraju ―mrežnim virusima‖. Ipak, za
razliku od virusa, ovi programi ne zahtevaju host programe i ne ugraĊuju
se uz glavne izvršne programe, već su samostalni programi sa
malicioznim dejstvom. Nastoje da se razmnoţavaju u što više primeraka,
što moţe izazvati zagušenje hard diska, mreţe ili e-mail servera. Poznati
crv Happy 99 exe prilikom pokretanja prikazuje vatromet, ali u pozadini
kreira nekoliko datoteka, a menja još nekoliko. Crv umnoţava svoje
kopije i širi se putem priloga e-mail poruka. Primeri poznatih crva su
Blaster worm i SQL Slammer worm.

- 241 -
2.4. Mobilni (aktivni) kôdovi

Mobilni kôd je aktivni program koji se prenosi sa udaljenog sistema

na lokalni sistem a zatim izvršava na lokalnom sistemu bez eksplicitne
instrukcije korisnika. Mobilni kôd ĉesto sluţi kao mehanizam za prenos
virusa i crva, ili Trojanaca do radne stanice korisnika. U drugim
sluĉajevima, mobilni kôd koristi ranjivosti sistema da izvrši svoje akcije,
kao što su neovlašćen pristup podacima ili kompromitacija ruta.
Popularni prenosioci mobilnih kôdova su Java applets, ActiveX,
JavaScript i VBScript.

2.5. Kombinovani napad (Blended Attack)

Kombinovani napad je sluĉaj malicioznog kôda koji koristi

višestruke metode za širenje. Vrlo poznati Nimda ―crv‖ je u stvari, primer
kombinovanog napada. Za širenje koriste:

 E-mail. Korisnik na ranjivom hostu otvori inficiran e-mail prilog;

Nimda traţi e-mail adrese na hostu, a zatim šalje svoje kopije na te
adrese.
 Windows zajedničke datoteke. Nimda skenira hostove traţeći
nezaštićenu zajedniĉku Windows datoteku; zatim moţe koristiti
NetBIOS kao prenosni mehanizam da inficira datoteke na tom hostu
u nadi da će korisnik aktivirati neku inficiranu datoteku, koja će
aktivirati Nimdu na tom hostu.
 Web serveri. Nimda skenira Web servere, traţeći poznate ranjivosti u
Microsoft-ovim sistemima na Internetu. Ako pronaĊe ranjiv server
pokuša da prenese svoju kopiju na server i inficira njega i datoteke.
 Web klijenti. Ako neki ranjivi Web klijent poseti neki Web server
koji je već inficiran sa Nimda, radna stanica klijenta će, takoĊe, biti
inficirana.

Tendencija korisnika je da većinu kombinovanih napada svrstavaju u

crve, kao Nimdu, koja sa tehniĉkog aspekta ima karakteristike virusa,
crva i mobilnog kôda.

- 242 -
3. MERE ZAŠTITE I OPORAVAK SISTEMA OD NAPADA

U cilju odbrane od dinamiĉki promenljivih pretnji sa Interneta i

potencijalnih malicioznih napada na mreţe, najsvrsishodnije je primeniti
razliĉite upravljaĉke, operativne i tehniĉke kontrole višeslojne zaštite,
najĉešće kombinovane kroz sledeće mere, metode i tehnike, [3]:

 višeslojna antivirusna zaštita, na kapiji, ruteru, serveru mreţe i

radnim stanicama; neki antivirusni skeneri sadrţe skript za
spreĉavanje Trojanaca;
 razvoj svesti o potrebi zaštite, obezbeĊuje nabavku programa samo
od poverljivih proizvoĊaĉa, primanje poruka samo od poverljivih
izvora, ne otvaranje sumnjive e-pošte, ne posećivanje ne-prijateljskih
lokacija (sajtova) i.t.d.;
 nadzor kontrolnih tragova, pregledom kontrolnih log datoteka,
ukljuĉujući logove barijera, a moţe detektovati abnormalne aktivnosti
u sistemu,
 pažljiva implementacija logičke AC i politike privilegija moţe
minimizirati uticaj malicioznih programa na rad sa nekom
aplikacijom;
 blokiranje aktivnog sadržaja sa mreţnim filterskim kapijama ili
podešavanjem zaštite na brauzeru klijenta moţe se spreĉiti unošenje
aktivnih malicioznih programa, ali se smanjuje funkcionalnost
sistema; digitalni potpis je alternativa za restrikciju aktivnog sadrţaja
prema poverljivim izvorima;
 izolacija sa mrežnom kapijom vrši se prema nepoverljivim mreţama
(npr. Internetu), ali maliciozni kôdovi mogu proći i kroz ove barijere.
Mogu se uneti i preko instalacionih programa iz prenosnih medija, ili
kapija sa ograniĉenim funkcijama. Barijere blokiraju pristup
udaljenih programa nekim portovima sistema. Efikasne su u
kombinaciji sa kapijom za aktivan sadrţaj;
 kriptološki mehanizmi zaštite tajnosti podataka i lozinki;
 primena tehnologije digitalnog potpisa, za proveru autentiĉnosti,
zaštitu integriteta podataka i obezbeĊenje neporecivosti izvršenih
aktivnosti; kontroleri integriteta detektuju ubacivanje logiĉkih bombi,
trapdors-a i virusne infekcije;
 procedura jake autentifikacije, bezbedna autentifikacija strana u
komunikaciji;
 korišćenje jakih ključeva i česta izmena, oteţava primenu metoda
kriptoanalize;

- 243 -
 zaštita adresa servera, zaštita od DoS napada;
 korišćenje digitalnih sertifikata, obezbeĊuje jednoznaĉne
identifikacione parametre;
 korišćenje smart kartica, za generisanje digitalnog potpisa i bezbedno
ĉuvanje kljuĉeva i drugih kriptografskih parametara.

Procedura za oporavak sistema i mere zaštite moraju biti deo strategije

borbe protiv napada malicioznih kôdova. Glavni zahtevi ove strategije su
osposobiti sistem i razviti procedure za: izolaciju inficiranih sistema,
uklanjanje malicioznog programa iz sistema,restauraciju (obično iz
rezervne kopije) integriteta sistema nakon napada i oporavak sistema.
Procedura za oporavak sistema mora biti jasno dokumentovana,
regularno testirana i da sadrţi proces za obavezno izveštavanje i akcije
korisnika u sluĉaju virusne infekcije. U borbi protiv virusa treba ukljuĉiti
poverljive provajdere zaštite (snabdevaĉe AV programa), zbog
akumuliranja znanja o vrsti napada, odbrani i proceni štete (gubitku
podataka) i resursa za oporavak sistema. U PRILOGU II 1A dati su
kriterijumi za izbor antivirusnih programa, elementi za izradu procedura
za oporavak i standardni stepeni kontrole intenziteta malicioznih
programa, [3].

U razvoju sistema zaštite i odbrane od malicioznih napada na sisteme u

mreţnom okruţenju, evidentan je problem identifikovanja razliĉitih
tipova zloupotreba mreţne infrastrukture, da bi se projektovale adekvatne
mere zaštite. Da bi studenti nauĉili da lakše identifikuju tipiĉne primere
zloupotreba RM, razvijena je Veţba GII P1A.

- 244 -
4. REZIME

Sa razvojem raĉunarskih mreţa i umreţavanja u sistem globalne

mreţe - Interneta, rastu i potencijalne opasnosti od razliĉitih napada sa
Interneta, ukljuĉujući brojne maliciozne programe i napade ljudskog
faktora (hakera, krakera, vandala i kompjuterskih terorista). Moguće su
brojne taksonomije pretnji u odnosu na razliĉite kriterijume. Krajnji cilj
svake taksonomije pretnji je da se specijalistima zaštite i korisnicima
obezbedi lakše definisanje i identifikovanje različitih tipova pretnji za IS.
Prema prirodi izvora pretnje se dele na slučajne-Sl i namerne-Na.
Sluĉajne su nenamerne ljudske greške u radu, kvarovi, prirodni vanredni
dogaĊaji i.t.d., koje se ne smatraju namernim napadima na sistem, ali su
ozbiljni uzroci bezbednosnih incidenata. Namerne pretnje za raĉunarske
sistema mogu se svrstati u 6 osnovnih grupa: maliciozne zloupotrebe
IKT, maliciozni kompjuterski kriminal, nebriga, ljudske greške, pad
sistema i okruženje. Naţalost iza svih malicioznih napada stoje ljudi, a ne
tehnologije, pa je profilisanje kompjuterskih kriminalaca izuzetno
znaĉajna aktivnost u borbi protiv kompjuterskog kriminala.

Kljuĉni tipovi napada mogu se svrstati u sledeće grupe napada hakera,

krakera, vandala i kompjuterskih kriminalaca: destrukcije, izmena
podataka, prekid servisa (DoS napad), špijunaža i neovlašćen korišćenje.

Za izvršavanje zloupotreba i kompjuterskog kriminala potrebni su motiv,

sredstvo i prilika. Opšti motivi hakera su znatiţelja, novac, moć, osveta
(nezadovoljni zaposleni i drugi, posebni - intelektualni izazov,
radoznalost i avanturizam, radi zabave, osećaj svemoći, potreba za
trijumfom, borba za prestiţ i dr. Sredstva su nivo veštine i tehnološki
kapaciteti sa kojima hakeri izvršavaju kriminal. Prilika za izvršavanje
kompjuterskog kriminala ili zloupotrebe je iskorišćena ranjivost i najteţe
se odreĊuje zbog mogućnosti postavljanja raznih vrsta zamki:
vremenskih tempiranih logiĉkih bombi, virusa, Trojanaca i.t.d. za
uklanjanje tragova napada.

Maliciozni program je kôd koji se tajno ubacuje u drugi program sa

namerom da se unište podaci, pokrenu destruktivni programi ili na drugi
naĉin kompromituje bezbednost i naruši poverljivost, integritet ili
raspoloţivost podataka, aplikacija ili napadnutog sistema. Generalno,
napadi sa malicioznim programima mogu se podeliti u pet kategorija:
virusi, Trojanci, crvi, mobilni kôdovi i kombinovani napadi.

- 245 -
Kompjuterski virus je program koji ˝inficira˝ ostale programe,
modifikujući ih tako da ukljuĉuju njegovu naprednu kopiju. Sa
inficiranog podruĉja, virus se moţe širiti kroz kompjuterski sistem i
mreţu, koristeći autorizaciju svakog korisnika da inficira njihove
programe. Svaki program koji se inficira, takoĊe se ponaša kao virus pa
se infekcija povećava. Trojanac, prosta forma zlonamernog programa,
ĉija je spoljna manifestacija naizgled interesantna korisnicima, prikazuje
poruke, briše datoteke ili diskove, ali ne inficira ostale izvršne datoteke,
jer se ne umnoţava (replicira), pa zato i nije u kategoriji virusa. Crvi su
maliciozni programi koji menjaju ili uništavaju podatke; mogu da šire
svoje kopije, ili njihove delove na druge raĉunarske sisteme, obiĉno
preko mreţa, pa ih neki autori smatraju virusima i svrstavaju u ―mreţne
viruse‖. Ipak, za razliku od virusa, crvi ne zahtevaju host programe i ne
prilepljuju se uz glavne izvršne programe, već su samostalni programi sa
malicioznim dejstvom. Mobilni kôd je aktivni program koji se prenosi sa
udaljenog sistema na lokalni sistem a zatim izvršava na lokalnom sistemu
bez eksplicitne instrukcije korisnika; ĉesto sluţi kao mehanizam za
prenos virusa i crva, ili Trojanaca do radne stanice korisnika.
Kombinovani napad je sluĉaj malicioznog koda koji za širenje koristi
višestruke metode: E-poštu, Windows zajedničke datoteke, Web servera,
Web klijenta i zajedničke datoteke u direktnoj arhitekturi sistema (peer-to
–peer). Sa tehniĉkog aspekta kombinovan napad ima karakteristike
virusa, crva i mobilnog koda.

Primarne mere višeslojne zaštite od malicioznih kodova su: razvoj svesti

o potrebi zaštite, antivirusni skeneri, kontroleri integriteta, nadzor
kontrolnih informacija, paţljiva implementacija logiĉke AC i politike
privilegija, blokiranje aktivnog sadrţaja i izolacija sa mreţnom kapijom i
dr. Procedura oporavka sistema i mere zaštite moraju biti deo strategije
borbe protiv malicioznih kodova..

- 246 -
5. KLJUĈNI TERMINI

Boot virusi: But virusi inficiraju sistem kada korisnik pokuša da butuje
sa inficiranog medija
Crv: kompletan program koji se umnoţava bez ˝inficiranja˝ ostalih
programa kroz repliciranje (kopiranje) samog sebe.
Haker: znatiţeljni mladi poznavalac raĉunara, koji neovlašćeno ĉeprka
po tuĊim raĉunarskim sistemima, uglavnom bez malicioznih namera, a u
ţelji za sticanjem novih znanja.
Kompjuterski kriminalci: rade sa ili bez raĉunara – kradu tuĊe
industrijske i nacionalne tajne, kradu novac, uništavaju datoteke, OS ili
menjaju podatke Web stranica ili baza podataka.
Logiĉka bomba: kôd ubaĉen u legitiman program, dizajniran da se
aktivira u tempirano vreme i proizvede rezultate koje legitimni korisnici
programa ne ţele.
Maliciozni kôd: neki program koji se tajno ubacuje u drugi program sa
namerom da se unište podaci, pokrenu destruktivni programi ili na drugi
naĉin kompromituje bezbednost ili integritet podataka u napadnutom
raĉunaru.
Mobilni malware kôd: nalazi se u aktivnom sadrţaju (JavaScript, Java
Applets i ActiveX) web dokumenta namenjenom za prezentaciju, ali i za
skrivanje mehanizma za napad na IKT sistem na kojem radi brauzer
klijenta.
Trojanac: program koji se ĉini atraktivan legitimnom korisniku (igrica,
alat), ali koji skriva malignu nameru (npr. kraĊa pasvorda). Trojanac se u
sistem ubacuje na brojne naĉine (e-mail, web servisi, prenosni mediji), a
poseban tip je daljinski upravljan program. Neki Trojanci prave tunele
kroz firewalls.
Virus: kod ubaĉen u legitiman program, napisan da se sam reprodukuje
kopiranjem u druge legitimne programe. Virusi mogu sadrţavati logiĉke
bombe, benigne ali uglavnom maligne.
Zamka (trapdor): metod dobijanja pristupa nekim delovima IKT sistema
izvan normalne procedure (npr. pristup bez davanja pasvorda). Kroz
zamku hakeri mogu ući u sistem kasnije. Zamku programeri mogu
ostaviti kao bag, koje kasnije otkrivaju hakeri.

- 247 -
6. LITERATURA

1. @stake, http://www.atstake.com,, 2006.

2. Apis security consulting, http://www.apisgroup.org, 2005.
3. Australian Communications, Electronic Security Instruction 33,
ACSI 33 Standard, 2002.
4. Barker William C., Guide for Mapping Types of Information and
Information Systems to Security Categories, NIST SP800-60 -1 i
2, www.nist.com, juni 2004.
5. Bosworth S., M.E.Kabay, Computer Security Handbook, John
Wiley & Sons, Inc., 2002.
6. CERT CA-1991-04, Social Engineering,
http://www.cert.org/advisories/ CA-1991-04.html, 1991.
7. CERT CA-1995-01, IP Spoofing Attacks and Hijacked terminal
connections, http://www.cert.org/advisories/ CA-1995-01.html,
1995.
8. CERT CA-1996-21, TCPSYN Flooding and IP spoofing Attacks,
http://www.cert.org/advisories/ CA-1996-21.html, 1996.
9. CERT CA-1998-01, Smurf IP Denial-of-Service Attacks,
http://www.cert.org/advisories/ CA-1998-01.html, 1998.
10. CERT CA-2000-02, Malicious HTML Tags Embedded in Client
Web requests,, http://www.cert.org/advisories/ CA-2000-02.html,
1995.
11. CERT IN-2002-03, Social Engineering Attacks Via IRC and
Instant Messaging, http://www.cert.org/incident_notes/IN-2002-
03.html, 2002.
12. Chappell L., You are Being Watched: Cyber Crime scans,
http://www.nwconnection.com/2001_03/cybercrime, 2001.
13. Ford W., M.S.Baum, Secure Electronic Commerce, Prentice Hall
PTR, 2001.
14. ftp://coas.sc.purdue.edu/pub/tools/unix/pwdutils
15. Grance T., Kent K., Kim B., Computer Security Incident
Handling Guide, NIST SP 800-61,
http://www.nist.gov/publications, January 2004.
16. http://securityresponse.symantec.com/avcenter/vinfodb.html.
http://www.cert.org/advisories/ CA-1991-04.html, 1991.
17. http://www.sophos.com/virusinfo.
18. http://www.trendmicro.com/vinfo/virusencyclo.
19. http://www.visionmagic.8m.com/ecasopis/avgust-01/virusi3.htm.

- 248 -
20. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
21. Oppliger R., Internet and Intranet Security, Artech House, 1998,
ISBN 0-89006-829, 1999.
22. Oppliger R., Security Technologies for the World Wide Web,
Artech House, ISBN 1-58053-045-1, 2000.
23. Persson E., Digital Identity Service in Sweden, Proc. of
Information Security Solution Europe Conference, ISSE 2002,
Paris, October 2-4, 2002.
24. Petrović R. Slobodan, Kompjuterski kriminal II Izdanje, MUP R.
Srbije, 2001.
25. RFC 792, RFC 1256, RFC 950, http://www.icann.rfcwditor.org,
2006.
26. Ruth A, Hudson K., Sertificat Security +, MicrosoftCo., CET
Beograd, 2004.
27. Schneier B., Applied Cryptography, John Wilez & Sons, Inc.,
1996.
28. Seymour B., Kagay m.e., Computer security handbook IV
izdanje, 2002.
29. Stremus P., ISS IDC Security, IDC simpozijum,
pstremus@iss.net, Beograd 2006.
30. www.kaspersky.com.

- 249 -
2. KONCEPTI ZA RAZVOJ PROGRAMA I SISTEMA ZAŠTITE

0. Uvod

Kada proučite ovo poglavlje naučićete:

- značaj razumevanja koncepta i metodologije zaštite

- prednosti i nedostatke koncepta reaktivne zaštite
- prednosti i nedostatke koncepta proaktivne zaštite

Stari inţenjerski metod za upravljanje promenama u bilo kojem

uspostavljenom sistemu poĉinje sa definisanjem tekućeg i ţeljenog
stanja. Kada se ovo uradi onda je lakše definisati kako će se izvršiti
tranzicija iz jednog u drugo bezbednosno stanje sistema. Ovaj
jednostavan, ali moćan pristup jedan je od najefikasnijih naĉina za
dugoroĉno strategijsko planiranje i definisanje strateškog plana ili
strategije zaštite IKT sistema.

Koncept sistema IKT zaštite obezbeĊuje odrţavanje bezbednosnog stanja

IKT sistema na ţeljenom (prihvatljivom) nivou rizika. Da bi se definisao
i razvio efektivan sistem IKT zaštite, treba definisati i dobro poznavati
osnovne pretnje i ciljeve zaštite, karakteristike i kvalitet IKT sistema kao
objekta zaštite i tehnologija zaštite. Misija sistema zaštite je zaštita IKT
objekata u ţivotnom ciklusu sistema, kroz izbor, instalaciju i odrţavanje
sistema zaštite na prihvatljivom nivou rizika od pretnji koje ga
ugroţavaju. U praksi, kontrolne funkcije zaštitnih mera i metoda biraju se
kao kombinacija atributa vrednosti ili osetljivosti objekata sistema,
ranjivosti sistema i pretnji, da bi se dostigla izbalansirana i
komplementarna zaštita, tj. sistem zaštite u kojem su manje efikasne
mere i metode zaštite zamenjuju sa efikasnijim merama i metodama, a
tehniĉke mere zaštite su praćene sa upravljaĉkim i operativnim
(proceduralnim, ne-tehniĉkim) merama, koje sve zajedno deluju
koherentno i obezbeĊuju oĉekivanu efektivnost sistema zaštite. Neki IKT
sistem smatra se da je optimalno zaštićen ako ima izbalansirane
bezbednosne funkcije (servise) i troškova akvizicije/razvoja sistema
kontrola zaštite. Optimalni sistem zaštite dobije se kada su troškovi
kontrola zaštite potpuno izjednaĉeni sa procenjenim potencijalnim
gubicima.

- 250 -
U praksi zaštite dogaĊa se upravo onaj incident koji nije planiran, a vrlo
ĉesto se program i sistem zaštite razvijaju neplanirano, kao reakcija na
poslednji napad, incident ili vanredni dogaĊaj, ili neusklaĊeno sa
analizom stvarnih rizika i potreba, što stvara redundantne i skupe sisteme
zaštite. TakoĊe, primena samo tehniĉkih kontrola zaštite predstavlja
parcijalno rešenje. Rezultat takve reaktivne zaštite je ojaĉani
(―okrpljeni‖) sistem zaštite sa puno preostalih ranjivosti.

Dinamiĉki promenljive kombinovane pretnje, stohatsiĉki karakter pojave,

intenziteta i uticaja ovih faktora rizika na informacije, IKT sistem i
poslove organizacija u celini, zahtevaju proaktivni pristup sa zaštitom od
poznatih i nepoznatih ranjivosti.

- 251 -
1. KONCEPT REAKTIVNOG SISTEMA ZAŠTITE

Koncept za razvoj programa i sistema zaštite na najvišem nivou

apstrakcije, treba da obezbedi glavne smernice i referentne okvire za
kljuĉne procese: definisanje korisniĉkih bezbednosnih zahteva,
definisanje bezbednosnih ciljeva, definisanje programa zaštite, razvoja
plana zaštite i projektovanja sistema zaštite, dokumentovanja programa
zaštite, razvoja/akvizicije, implementacije i odrţavanja sistema zaštite
[10].

U procesu razvoja programa zaštite i projektovanja sistema zaštite

generalno se koriste tri osnovne metodologije: politika zaštite,
upravljanje rizikom i najbolja praksa zaštite.

Prve dve metodologije zaštite obuhvataju koncept klasiĉne reaktivne

zaštite, ili zaštite planirane i implementirane da reaguje na poznate
napade, a treća - koncept proaktivne zaštite IKT sistema od dinamiĉki
promenljivih, kombinovanih poznatih i nepoznatih pretnji sa Interneta.

1.1. Koncept reaktivne zaštite

Barijere (Firewalls) i antivirusni programi nisu mogli zaustaviti ni

jedan od 4 glavna napada poĉetkom 2006 godine. Zaštita od malicioznih
programa koje koriste ranjivosti (eng. exploits) i poznatih virusa je
koncept reaktivne zaštite. Reaktivni koncept zaštite u većini sluĉajeva
suviše kasni, a nove varijante napada ĉine nekorisnim prethodno
aţurirane definicije virusa. Reaktivni koncept je tipiĉan za većinu
savremenih IDS/IPS sistema, [12].

Iz prakse zaštite poznato je da se u IKT sistemu dogodi upravo onaj

incident koji nije planiran i za kojeg se misli da se nikada neće dogoditi.
Program zaštite vrlo ĉesto se razvija neplanirano, kao reakcija na
poslednji napad, incident ili vanredni dogaĊaj, ili neusklaĊeno sa
analizom stvarnih rizika i potreba, stvarajući redundantne i skupe sisteme
zaštite. TakoĊe, vrlo ĉesta primena samo tehniĉkih kontrola zaštite
predstavlja parcijalno rešenje. Rezultat takve reaktivne zaštite je samo
―okrpljeni‖ sistem zaštite sa puno preostalih ranjivosti.

Korišćenje neke od razvijenih kvalitativnih ili kvantitativnih metoda za

analizu rizika u kombinaciji sa operativnom metrikom, kao što su broj

- 252 -
blokiranih upada ili virusnih napada, omogućava izbor rentabilnih,
optimalnih sistema zaštite, opravdanje troškova zaštite, edukovanje o
potrebi zaštite i dobijanje podrške od najvišeg rukovodstva organizacije
[15].

Sa metodološkog aspekta, razvoj reaktivnog sistema zaštite najbolje se

moţe predstaviti procesom upravljanja rizikom. Glavna komponenta
upravljanja rizikom je analiza i procena rizika. Cilj procene rizika je
ublaţavanje, izbegavanje ili smanjenje rizika. Prvi korak u procesu
redukcije rizika je objektivna kontrola (audit) , analiza postojećeg
sistema zaštite i ranjivosti IKT sistema i identifikacija realnog stanja
zaštite. Redukcija rizika odvija se najmanje u pet (do sedam) koraka koje
nije lako realizovati (v. G. III, p. 2):

1. Odrediti kritiĉne operacije i funkcije IKT sistema, bitne za

kontinuitet poslovanja;
2. Identifikovati sisteme i personal bitne za kontinuitet poslovanja
organizacije;
3. Evaluirati scenario pretnji za ove operacije i njihove sisteme;
4. Izvršiti analizu rizika, a rezultate koristiti za razvoj programa i
sistema zaštite;
5. Na bazi programa i politike zaštite razviti slojeviti sistem zaštite
po dubini.

U svakom reaktivnom konceptu zaštite treba imati u vidu da je poverenje

u IKT sistem i organizaciju u celini uvek poslednja „prepreka― za svaki
program i projekat sistema zaštite. Naime, organizacije koje mogu imati
ĉak identiĉne tehnologije zaštite, mogu imati sisteme zaštite kojima se ne
moţe jednako verovati. Tu delikatnu razliku u stvarnom vrednovanju
sistema zaštite ĉine obuĉenost, motivacija i samopouzdanje projektanata,
izvoĊaĉa i administratora zaštite konkretnog IKT sistema, a vrednuje se i
procenjuje metodama sertifikacije za razvoj bezbednosne pouzdanosti ili
garancije (assurance), ili sigurnosti korisnika/vlasnika da je sistem
zaštićen, a time i bezbedan, [12].

- 253 -
1.1.1. Funkcionalni model koncepta reaktivne zaštite

Koncept reaktivne zaštite podataka i informacija je neprekidan,

dinamiĉki promenljiv, cikliĉni proces (kruţni proces sa povratnom
spregom). Funkcionalni model koncepta reaktivne zaštite sadrţi sledeće
glavna faze: identifikacija stanja zaštićenosti sistema, procene rizika,
planiranja poboljšanja sistema zaštite, implementacije novih ili
poboljšanih kontrola zaštite i operativnog održavanja i permanentnog
nadzora i kontrole, i obuke i obrazovanja u zaštiti, (Sl 1.1), [17].

Procena rizika
Identifikacija stanja
IKT bezbednosti &
Politika zaštite

Nadzor i kontrola
&
Svest i obuka u zaštiti

Planiranje/
Implementacija i
projektovanje
odrţavanje
programa i sistema
sistema zaštite
zaštite

Sl. 1.1. Funkcionalni model koncepta reaktivne zaštite

Opšti funkcionalni modeli koncepta za upravljanje sistemom reaktivne
zaštite mogu se definisati na više naĉina i sa razliĉitih aspekata. Na
primer, prihvatljiv funkcionalni model bezbednosti i zaštite IKT sistema
obuhvata 5 komponenti zaštite [10]: upravljanje i planiranje zaštitom,
izbor tehničkih kontrola za upravljanje zaštitom, koncepti i modeli
zaštite, razvoj/akvizicija i selekcija sistema zaštite i uputstvo za
upravljanje sistemom zaštite.
1. Upravljačke kontrole zaštite obuhvataju: upravljanje programom
zaštite, upravljanje rizikom, planiranje ţivotnog ciklusa sistema zaštite,
akviziciju sistema i servisa zaštite, reviziju kontrola zaštite i autorizaciju
prava pristupa i ovlašćenja.
2. Tehničke kontrole sistema zaštite obuhvataju identifikaciju i
autentifikaciju; logiĉku kontrolu pristupa; nadzor i kontrolu rada;
kriptografske metode (digitalni potpis i peĉat, kriptozaštita, PKI, VPN,
...).

- 254 -
3. Koncept slojevitog sistema zaštite sadrţi 12 kljuĉnih komponenti
(kategorija):

1. Rukovodilac sistema zaštite – specijalista koji kontroliše ostale

elemente zaštite;
2. Upravljanje rizikom – širok spektar procesa za analizu i procenu
rizika i upravljanje rizikom izborom rentabilnih mera (kontrola)
zaštite;
3. Kontrola pristupa, identifikacija/autentifikacija;
4. Barijere (firewalls);
5. Aktivni filteri sadrţaja;
6. IDS/IPS;
7. Skeneri virusa;
8. Kriptozaštita;
9. Testiranje upada u sistem;
10. Propisna administracija sistema;
11. Softversko upravljanje politikom zaštite i
12. Plan za upravljanje incidentom i oporavak sistema (nastavak
poslovanja).

4. Razvoj/akvizicija i selekcija sistema zaštite obuhvata: projektovanje,

razvoj i implementaciju tehniĉkih kontrola zaštite (mehanizama i
protokola), razvoj plana evaluacije i izvoĊenje testova na proboj sistema
zaštite, integraciju kontrola sistema zaštite, verifikaciju (sertifikaciju)
kontrola zaštite i akreditaciju sistema zaštite.
5. Uputstvo za upravljanje sistemom zaštitom obuhvata kontrole i
instrukcije za upravljanje promenama u konfiguraciji sistema,
operativnom okruţenju i procenu njihovog uticaja na sistem zaštite.

Menadţment (kontrola i upravljanje) sistema zaštite u raĉunarskim

mreţama OSI (Open System Interchange) tipa arhitekture, mora podrţati
sve administrativno nametnute preporuke politike zaštite. Entiteti koji su
obuhvaćeni jedinstvenom politikom bezbednosti i zaštite, u sistemu kojeg
administrira jedan autoritet, organizuju se u jedinstvenu domenu zaštite.

Menadţment OSI sistema zaštite obuhvata menadţment servisa i

mehanizama zaštite OSI sistema. Primeri menadţmenta sistema zaštite
su: distribucija kriptografskih kljuĉeva, izveštavanje o kompjuterskom
incidentu, aktiviranje i dezaktiviranje servisa zaštite, postavljanje
parametara politike zaštite i sl.

- 255 -
Zaštitna baza podataka (ZBP) je konceptualno skladište (repozitorijum)
svih relevantnih informacija za menadţment višeslojne zaštite IKT
sistema OSI arhitekture. Svaki krajnji sistem treba da sadrţi lokalne
informacije koje im omogućavaju da primene odgovarajuću politiku
zaštite. ZBP je distribuirana baza podataka u meri neophodnoj da se
primeni konzistentna politika zaštite u grupi krajnjih sistema. U praksi
zaštite, delovi ZBP mogu, ali ne moraju biti integrisani u bazu podataka.
ZBP moţe se realizovati kao: tabela podataka, datoteka i podaci ili
pravila unutar softvera ili hardvera realnog OSI sistema.

1.1.2. Ocena kvaliteta sistema reaktivne zaštite

U postojećem reaktivnom konceptu zaštite IKT sistema, organizacije

u Internet okruţenju generalno imaju tri moguća, relativno skupa, spora i
u suštini reaktivna rešenja, i to da:

1. ne preduzimaju ništa, ili

2. primenjuju manuelne metode bezbednosnih popravki
(„zakrpama―), ili
3. izvrše „ad hock‖ samozaštitu sa izolovanim rešenjima na
distribuiranim taĉkama.

Prvi sluĉaj najĉešće se zasniva na uverenju „da se to neće baš nama

dogoditi―. Dakle, nema razloga trošiti novac na zaštitu, sve dok ne
postoji dokaz da je IKT sistem organizacije stvarno ugroţen. Naţalost,
dokaz o postojanju rizika obiĉno dolazi, kao rezultat uspelog napada, u
formi prekida rada, nekog oblika zloupotreba, materijalnih i
nematerijalnih gubitaka. Sliĉno je kada organizacija ima samo mreţnu
barijeru (firewall), ili neku statiĉku formu infrastrukture zaštite. Barijere
su znaĉajni mehanizmi zaštite, ali ih napadaĉi lako zaobilaze i pruţaju
nedovoljnu zaštitu za online reţim rada, [12].

Manuelna i improvizovana zaštita predstavlja stari metod reaktivne

zaštite. Teoretski je moguće pratiti sve moguće izvore pretnji, preuzeti
sve relevantne bezbednosne zakrpe vrućih taĉaka i zatim testirati i
instalirati svaku od njih na svakom potencijalno ugroţenom RS u RM.
MeĊutim, potrebno je znaĉajno vreme za identifikovanje, fiksiranje i
testiranje potencijalno ranjivih RS u mreţi, što je kritiĉno u sluĉaju
neposrednog rizika od napada IKT sistema u Internet okruţenju. TakoĊe,
zahteva se mnogo intenzivnog rada, pošto se svaki RS mora pojedinaĉno

- 256 -
analizirati. Rezultati su obiĉno predvidljivi. Suoĉeni sa vremenskim
pritiskom, neke ranjivosti promaknu i najboljim specijalistima zaštite,
zakrpljene ranjivosti ostaju nepredvidljive zbog slabog poznavanja
interakcije nove zakrpe sa drugim servisima zaštite. Dakle, manuelno
fiksiranje ranjivosti sistema je neprihvatljivo, skupo, vremenski
zahtevno, neprecizno, nepotpuno i obavezno reaktivno. U odnosu na prvu
opciju, ni ovo rešenje ne obezbeĊuje valjanu strategiju zaštite.
Strategija relativno spore i skupe zaštite sa neusaglašenim rešenjima na
izolovanim, distribuiranim taĉkama IKT sistema, trenutno preovlaĊuje u
svetu. Ova strategija reaktivne zaštite obuhvata slojevitu zaštitu po dubini
i na više nivoa, sa više razliĉitih komponenti zaštite za procenu ranjivosti
sistema, kao što su detektori upada u sistem (IDS), skeneri saobraćaja i
alati za forenziĉku analizu raĉunarskih mreţa, servera, raĉunara,
programa i aplikacija. Upravljanje ovakvim sistemom zaštite vremenski
je zahtevno, skupo i kompleksno. Iako predstavlja efektivno rešenje za
jednu ili dve specifiĉne namene, ovakav sistem zaštite ne obezbeĊuje
koherentnu, integralnu i uniformnu zaštitu IKT sistema. Bez
centralizovanog upravljanja sistemom zaštite ovaj sistem ne obezbeĊuje
analizu i vremensku korelaciju velikog broja bezbednosno relevantnih
podataka i njihovu razmenu u realnom vremenu, pa su organizacije
primorane da samostalno reaguju na bezbednosne incidente i
preduzimaju skupe mere za oporavak sistema.
Na Sl. 1.2. prikazan je vremenski prozor bezbednosne funkcije (zaštite)
klasiĉnog reaktivnog sistem zaštite (sa razliĉitim rešenjima zaštite i sa
manuelnim otklanjanjem ranjivosti sistema) koji se nalazi izmeĊu
vremena objavljivanja iskorišćenja odreĊene ranjivosti i manuelnog
otklanjanja iskoristivih ranjivosti primenom generisanih zakrpa [11].

- 257 -
 Sl. 1. 2. Vremenski prozori zaštitne funkcije reaktivnih sistema
zaštite, [11]

Sve mere zaštite u reaktivnoj zoni zaštite ograniĉene su na reaktivno

ĉišćenje, saniranje i oporavak sistema, sa uţurbanim prikupljanjem
razbacanih delova i rekonstrukcijom rada sistema. Manuelno krpljenje
ostaje u ovoj reaktivnoj zoni, pošto se suviše brzo širi već poznata
iskoristiva ranjivost, pre nego što zakrpa postane efektivna. U praksi,
zakrpe se ĉesto ne apliciraju dugo vreme od objavljivanja da je neka
ranjivost iskorišćena.

Razliĉita rešenja postojećih sistema reaktivne zaštite, takoĊe se nalaze u

ovoj zoni, pošto ona nemaju potrebnu brzinu i preciznost da obezbede
proaktivnu zaštitu. Većina postojećih rešenja zaštite fokusira se na
otkrivanje ranjivosti sistema. MeĊutim, pre nego što saniraju ranjivost,
moraju utrošiti vreme na analizu ranjivosti nakon njihovog otkrivanja i
na ĉekanje objavljivanja adekvatne zakrpe.

Administratori reaktivnog sistema zaštite nemaju realne mogućnosti da

izdvoje kritiĉne ranjivosti od minornih, a jednostavan IDS nije dovoljan
za preduzimanje aktivnosti, sve dok proces napada ne bude u toku. Osim
toga, za analizu incidenta podaci se skupljaju manuelno sa razliĉitih
taĉaka (iz log datoteka distribuiranih RS) i u raznim formatima, što
znatno usporava i oteţava analizu dokaza i incidenta. Dakle, ovakvo
rešenje sistema zaštite zahteva dodatne aktivnosti u procesima razvoja,
konfigurisanja, analize, aţuriranja i odrţavanja sistema zaštite. Ova
manuelna i poluautomatska rešenja strategije zaštite danas su standardna
i obezbeĊuju nedovoljno jaku, ali kontrolisanu zaštitu na prihvatljivom

- 258 -
nivou rizika. Sam koncept reaktivne zaštite je po svojoj prirodi
proaktivna aktivnost, a reaktivni karakter odreĊuje reagovanje samo na
poznate ranjivosti.

- 259 -
2. KONCEPT PROAKTVNE ZAŠTITE

Prvi korak u razvoju koncepta proaktivne zaštite je korišćenje baza

znanja i drugih servisa najbolje prakse zaštite. Na primer, baza znanja
MeĊunarodnog konzorcijuma za bezbednost IKT sistema - ISC CBK
(International Security Consorcium - Common Body of Knowladge),
omogućava menadţerskoj strukturi i krajnjim korisnicima sopstveni
razvoj i upravljanje zaštitom, obuhvatanjem 10 relativno odvojenih
komponenti zaštite:

1. Praksa upravljanja zaštitom IKT sistema;

2. Arhitektura i modeli sistema zaštite;
3. Metodologija i sistemi kontrole pristupa;
4. Zaštita razvoja aplikacija;
5. Zaštita funkcionisanja IKT sistema (operativna zaštita);
6. Fiziĉka zaštita;
7. Kriptografska zaštita;
8. Zaštita telekomunikacija, raĉunarskih mreţa i Interneta;
9. Planiranje kontinuiteta poslovanja (upravljanje vanrednim
dogaĊajem i kompjuterskim incidentom, akreditacija i
sertifikacija sistema) i
10. Istraga zloupotreba IKT sistema (zakonski okvir, etiĉke norme).

U ovoj bazi znanja derivirane su upravljaĉke, operativne i tehniĉke

kontrole zaštite za niske, srednje i visoke nivoe rizika, definisane, kratko
opisane i svrstane u kataloge kontrola zaštite, koji sa katalogom
kontrola najbolje prakse predstavljaju osnovna uputstva korisnicima za
definisanje programa zaštite, upravljanje i projektovanje sistema zaštite.

Koncept proaktivne zaštite obezbeĊuje zaštitu od korišćenja ranjivosti i

malicioznih napada, zaustavljanjem pretnji na samom izvoru, koristeći
najsavremenije tehnologije zaštite. Pretnje sa Interneta koriste ranjivosti
OS, aplikacija ili mreţne infrastrukture, da bi se realizovale sa uspešnim
napadom (Sl. 2.1), [12].

- 260 -
 Sl. 2.1. Iskoristive ranjivosti IKT sistema

Novi koncept proaktivne zaštite obezbeĊuje veću rentabilnost vremena i

troškova od postojećih reaktivnih sistema zaštite, koji uglavnom reaguju
na incidente. Idealan zahtev je da sistem zaštite reaguje maksimalno brzo
i precizno na dinamiĉki promenljive, kombinovane pretnje. Savremeni
sistemi zašite troše velika finansijska sredstva za restauraciju stanja
sistema (planiranje, bekapovanje i oporavak) od nepredvidljivog, ĉesto
samo jednog napada. Otuda je u oblasti zaštite oduvek postojala ţelja da
se vrši rentabilna proaktivna detekcija i zaštita od poznatih i nepoznatih
napada. Korišćenjem proaktivnog sistema u poreĊenju sa klasiĉnim,
postojećim sistemima reaktivne zaštite, postiţe se velika ušteda u
vremenu, analizi i upravljanju rizikom i sistemom zaštite.

- 261 -
2.1. Funkcionalni model proaktivne zaštite

Metodologija proaktivne zaštite obuhvata mehanizme zaštite na više

nivoa, sa razliĉitim brzinama reakcije i taĉnosti, sa većom ukupnom
efektivnošću, redukovanim operativnim rizikom i znatno niţim
troškovima razvoja, operativnog rada i odrţavanja sistema zaštite.

Koncept proaktivne zaštite od dinamiĉki promenljivih pretnji (DPP

zaštita) nudi novi proaktivni pristup, u kojem se zaštita moţe ostvariti
kombinacijom, [11]:

1. baze znanja svetski vodećih obaveštajnih mreţa CIRT i

CERT timova za povećanje brzine i taĉnosti reagovanja na
nove napade i ranjivosti sistema,
2. vodeće tehnologije za IKT zaštitu, koja obezbeĊuje
proaktivnu zaštitu: detekciju napada (incidenta), zaštitu od
posledica napada i adekvatni odgovor na napad na mreţu,
servere i radne stanice i
3. procesnog pristupa pojednostavljenog sistema zaštite, koji
obezbeĊuje proaktivnu zaštitu od poznatih i nepoznatih
pretnji.

Baze znanja (na primer X-Task Force tima Internet Security System –
ISS), obezbeĊuje aţuran bilten zaštite (X-Press Updates) u kojem
objavljuje oko 45% ranjivosti aktuelnih operativnih sistema i drugih
programa u svetu, odnosno, 3 puta više od drugih sliĉnih entiteta u svetu.
Cilj aktivnosti X-Force je prikupljanje informacija koje pomaţu da se
shvati kako sistemi mogu biti kompromitovani. U toku 2004. godine X-
Force je detaljno opisala više od 3.300 ranjivosti softvera i 5.100 u 2005.
godini, od ĉega je 1/3 rangirana kao visoko riziĉne ili kritiĉne ranjivosti
za poslovne infrastrukture. Na slici Sl.2.2. grafiĉki je prikazan procenat
ukupno otkrivenih visoko riziĉnih ranjivosti u svetu u periodu 1998-
2005. godine od strane razliĉitih entiteta, [16].

- 262 -
Sl. 2.2. Procenat otkrivanja ranjivosti IKT sistema u periodu 1998-
2005

- 263 -
Vrhunska tehnologija proaktivne zaštite obezbeĊuje automatizaciju
ciklusa zaštite i unosi elemente ekspertnih sistema. Tehnologija
proaktivne zaštite obuhvata sledeće kljuĉne komponente sistema:

1. Centralna jedinica sistema zaštite (Protection Engine), koji

sadrţi tri kljuĉna elementa (IPS–Intrusion Protection System,
Protection Engine i Modul za reagovanje na incidente)
objedinjena u jedinstven ureĊaj; obezbeĊuje nelinearne funkcije
zaštite, pokreće IPS/IDS agente kroz RM, servere, RS i aplikacije,
koji detektuju, spreĉavaju i reaguju na poznate i nepoznate
napade.
2. Komandna jedinica (Site Protector), koja obezbeĊuje komande i
centralizovano upravljanje dogaĊajima u RM, serveru i
mehanizmima zaštite RS.
3. Integrator sistema (Fusion System), koji vrši obradu signala,
obezbeĊuje prepoznavanje obrazaca napada i analizira uticaje
DPP napada, minimizira laţne alarme i smanjuje ukupne troškovi
zaštite.
4. Modul za ažuriranje (X-Press Updater), koji automatski aţurira
bazu podataka o napadima. Pripremaju ga CERT/CIRT timovi za
skupljanje informacija o napadima i ranjivostima IKT sistema,
[4].

DPP Protection Engine obezbeĊuje realizaciju mehanizama DPP zaštite,

a ugraĊuje se u sva rešenja ISS kao što su, [11]: skeneri sistema zaštite
(Internet skener, Sistem skener, Skener baze podataka i Skener bežične
mreže),softversko-hardverski mreţni senzori i detektori upada
(RealSecure 10/100, RealSecure Gigabit Network, RealSecure za Nokia,
RealSecure za Crossbeam, i Proventia A), softverso-hardverski sistemi
za spreĉavanje napada (Proventia G), višefunkcionalni ureĊaji za zaštitu
(Proventia M), sistem detekcije napada na nivou servera (Real Secure
server) i sistem detekcije napada na nivou radne stanice (Real Secure
Desktop).

Procesni pristup zaštiti i pojednostavljeni proces zaštite bitna je

komponenta koncepta proaktivne DPP zaštite. Borba protiv novih i
nepoznatih pretnji zahteva brzo reagovanje na otkrivenu iskoristivost
ranjivosti, a ne kada se iskoristiva ranjivost već iskoristi na objektu IKT
sistema. Zato DPP rešenja koriste jedinstveni mehanizam virtuelne
zakrpe (Virtual Patch) za automatsko saniranje ranjivosti sistema. Na

- 264 -
primer ISS Proventia, radi tako što obezbeĊuje privremeni zaklon ili
―virtuelne bezbednosne popravke (zakrpe)‖ za poznate ranjivosti, koje:

– obezbeĊuju zaštitu u nultom danu, spreĉavajući iskorišćenje

ranjivosti,
– blokiraju sve varijante pretnji (ukljuĉujući i nepoznate),
– ne oslanjaju se na definicije (potpise) malicioznih programa,
– eliminišu potrebu hitnih bezbednosnih popravki,
– otklanjaju rizik da popravka moţe naneti neku štetu,
– omogućavaju primenu bezbednosnih popravki u toku procesa
normalnog odrţavanja programa i hardvera i uobiĉajenih
hakerskih napada.

Ovaj mehanizam omogućava organizaciji da trenutno u realnom vremenu

zaštiti sistem od poznatih i nepoznatih napada, praktiĉno u trenutku kada
se ranjivost otkrije, što je ĉesto znatno ranije od trenutka zvaniĉnog
generisanja i objavljivanja na Internetu zakrpa za novo-otkrivene
ranjivosti sistema.

Na slici 2.3. na vremenskoj osi prikazana je zona (vremenski prozor)

proaktivne zaštite, [11].

Sl. 2.3. Zona proaktivne zaštite, [11]

Proces proaktivne zaštite startuje sa otkrivanjem ili javnim

objavljivanjem ranjivosti sistema (vulnerability discovered/disclosed).
Zatim sledi generisanje napada (exploit released), koji moţe iskoristiti
otkrivenu ranjivost sistema (generisanje iskoristivosti te ranjivosti), ali
obavezno ne mora. Konaĉno, generiše se i aplicira nova bezbednosna
popravka-zakrpa (patch applied) za otklanjanje ove iskoristive ranjivosti.

- 265 -
Iako je vreme od otkrivanja do iskorišćenja ranjivosti promenljivo,
zakrpa se obiĉno aplicira tek kada je šteta već naneta, iz tri sledeća
razloga:
1. potrebnog vremena za manuelno krpljenje ranjivosti
distribuiranih RS,
2. raspoloţivosti zakrpa za nove ranjivosti, tek kada su ranjivosti
iskorišćene i
3. sve kraćeg vremena izmeĊu otkrivanja ranjivosti i njenog
iskorišćenja
U vremenu od otkrivanja ranjivosti sistema, a pre njenog iskorišćenja,
nalazi se prozor zone delovanja proaktivne zaštite. U ovoj taĉki
otkrivanja ranjivosti sistema aktivira se Virtual Patch proces, sistem za
proaktivnu zaštitu se aţurira i obezbeĊuje zaštitu i bez poznavanja
informacije o iskoristivosti te ranjivosti sistema, koja se moţe generisati
znatno kasnije.
Dakle, zona proaktivne zaštite od dinamiĉki promenljivih pretnji (DPP),
prikazana na Sl. 2.3, obezbeĊuje se upotrebom Virtual Patch procesa, a
fokusira se na period posle otkrivanja ranjivosti, a pre vremena njenog
iskorišćenja, obezbeĊujući tako neophodnu brzinu i taĉnost zaštite od
nepoznatih pretnji. U stvari, proaktivna zona zaštite ne obuhvata samo
DPP vremenski period – nego se proteţe i na zonu pre otkrivanja
ranjivosti sistema (Sl. 2.4), što omogućavaju stalni procesi: istraţivanja i
dubokog razumevanje prirode ranjivosti, ranog upozorenja o otkrivenim
ranjivostima (ISS - obiĉno 30 dana pre javnog otkrivanja, a 24 sata ranije
za ranjivosti koje otkriju drugi entiteti) i automatskog aţuriranja
bezbednosno relevantnih informacija, dobijenih od svog istraţivaĉkog
CERT tima.

Sl. 2.4. Prošireni vremenski prozor zaštitne funkcije proaktivnih

sistema zaštite, [11]

- 266 -
Konaĉan rezultat svih ovih aktivnosti je proaktivna zaštita od nepoznatih
napada. Ukratko Virtual Patch proces obezbeĊuje rezervno vreme,
omogućavajući organizaciji da bezbedno ĉeka dok se ne pojavi dovoljno
aţurna bezbednosna popravka (update), koja ne zahteva individualno
krpljenje i manuelno rebutiranje sistema. Kao kod preventivnog
odrţavanja automobila i Virtual Patch obezbeĊuje preventivno
odrţavanje sistema zaštite i redefiniše odrţavanje sistema bezbednosti,
tako da se bezbednosne operacije izvršavaju kao deo normalnog procesa
upravljanja promenama IKT sistema, što omogućava mnogo efektivnije i
efikasnije planiranje resursa i brţi vremenski odziv na poznate i
nepoznate pretnje.

Familiju komponenti sistema proaktivne zaštite ĉine i komponente:

Upravljanje ranjivostima (Vulnerability Management), IDS (Intrusion
Detection System), IPS (Intrusion Prevention System) i Upravljani
servisi zaštite (Managed Protection Services). Najnoviji proizvod
preventivni antivirusni sistem-VPS (Virus Prevention System) koji se
instalira na mreţnoj kapiji (Gateway) i Desktop PC raĉunaru, sadrţi
tehnologiju baziranu na praćenju realnih napada koja: otkriva nepoznate
(0-dana) napade, zaustavlja trku sa napadaĉima i ne zahteva aţuriranje
definicija malicioznih programa. VPS na Gateway-u spreĉava nove
viruse da uopšte prodru u mreţu. Primarni mehanizam za propagaciju
virusa je kroz e-poštu. Zaustavljanjem ovih malicioznih programa na
Gateway-u postiţu se višestruke uštede u operativnom korišćenju RM,
prostoru za e-poštu na HD, stabilnosti sistema e-pošte i dr.

- 267 -
2.2. Ocena kvaliteta proaktivne zaštite

Korišćenjem proaktivnog sistema zaštite, u poreĊenju sa klasiĉnim,

reaktivnim postojećim sistemima zaštite, postiţe se velika rentabilnost u
vremenu, analizi i upravljanju rizikom. Glavni atributi sistema zaštite
postaju taĉnost i brzina. Kako pretnje i ranjivosti rastu, sistem zaštite
mora biti brţe aktiviran i što je moguće precizniji. Napadaĉima treba
svega 1% margine greške da budu efektivni. Sveobuhvatno istraţivanje
napada i ranjivosti je kljuĉni faktor proaktivne zaštite.

Centralna platforma za DPP zaštitu je jezgro jedinstvenog proaktivnog

sistema za zaštitu i obezbeĊuje znatno bolju zaštitu cele RM, servera, RS
i aplikacija, smanjujući kompleksnost i troškove zaštite, u odnosu na
postojeće reaktivne sisteme zaštite.

Efektivnost DPP zaštite dolazi otuda što integriše centralne platforme

zaštite i vrhunsku tehnologiju zaštite, obezbeĊujući njihov rad u okviru
iste strukture. MeĊusobna razmena kritiĉnih, bezbednosno relevantnih
informacija izmeĊu agenata zaštite, obezbeĊuje brţe razumevanje
obrazaca nepoznatih napada. Jedinstvena politika zaštite, koja se generiše
centralizovano, omogućava centralizovano i koordinirano upravljanje
analizom podataka i izveštavanjem o tehniĉkim i upravljaĉkim
kontrolama. Sistem zaštite, bez mogućnosti vremenske korelacije
bezbednosnih dogaĊaja, moţe poslati upozorenje, ali će vrlo ĉesto
generisati laţni alarm. Centralizovano upravljan sistem zaštite sa
jedinstvenom vremenskom korelacijom bezbednosno relevantnih
dogaĊaja eliminiše laţne alarme. Eliminacija laţnih alarma znatno
smanjuje ukupne troškove odrţavanja zaštite, ĉime se pribliţavamo
optimalnom sistemu zaštite. Sistem DPP zaštite ima tri osnovne
prednosti u odnosu na reaktivni sistem zaštite, a to su: brzina, taĉnost i
pouzdanost (manji broj laţnih alarma) i veći nivo zaštite za ista
finansijska ulaganja. U PRILOGU II 2A prikazana je zbirna Matrica
prednosti sistema proaktivne DPP zaštite u odnosu na reaktivne sisteme
zaštite.

- 268 -
3. REZIME

Savremen potrebe za bezbednošću i zaštitom IKT sistema zahtevaju

razvoj inteligentne, sveobuhvatne i u što većoj meri adaptivne strategije
zaštite. U procesu razvoja programa zaštite i projektovanja sistema
zaštite generalno se koriste tri osnovne metodologije: politike zaštite,
procene rizika i korišćenje baza znanja najbolje prakse zaštite. Prve dve
metodologije obuhvataju koncept reaktivne zaštite od poznatih pretnji, a
treća – proaktivne zaštite od poznatih i nepoznatih pretnji.

Koncept reaktivne zaštite bazira se na sprovoĊenju predefinisanih

politika zaštite i procesu upravljanja rizikom, koji inherentno zahteva
balansiranje izmeĊu reaktivnih i proaktivnih aktivnosti u oblasti zaštite
IKT sistema. U procesu analize rizika korisno je i preporuĉuje se
ispitivanje scenarija pretnji na bazi procenjenog rizika, koji praktiĉno
modelira oĉekivane pretnje i njihov uticaj na procenjene i poznate
ranjivosti sistema. Sam koncept reaktivne zaštite je po svojoj prirodi
proaktivna aktivnost, a reaktivni karakter odreĊuje reagovanje samo na
poznate ranjivosti.

Koncept proaktivne DPP zaštite (od dinamiĉki promenljivih,

kombinovanih pretnji) neuporedivo efikasniji i efektivniji, uspešno
zamenjuje postojeće skupe, reaktivne i spore sisteme zaštite. DPP zaštita
obezbeĊuje pojednostavljen, integralan sistem zaštite koji reducira broj
osoblja i softverske resurse, a bitno poboljšava i ubrzava sveukupan
proces zaštite. Koncept proaktivne DPP zaštita ostvaruje se
kombinacijom baze znanja o novim napadima i ranjivostima sistema,
vodeće tehnologije za proaktivnu zaštitu (detekciju napada i adekvatni
odgovor) i procesnog pristupa pojednostavljenog sistema zaštite i ima tri
osnovne prednosti u odnosu na reaktivni sistem zaštite, a to su: brzina;
taĉnost i pouzdanost (manji broj laţnih alarma i veći nivo zaštite za ista
finansijska ulaganja.

- 269 -
4. KlJUĈNI TERMINI

Koncept: osnovna zamisao, ideja, idejno rešenje, model.

Metod: naĉin rada.
Metodologija: nauka o metodima; sistem organizovanja: principa
(logiĉke metodologije - indukcija, dedukcija, generalizacija, analiza,
sinteza, apstrakcija, uspostavljenih principa, i.t.d.); koncepata (idejnih
rešenja, modela zasnovanih na principima); alata (za implementaciju
koncepata) i metoda i tehnika (koje definišu naĉin primene alata i
procedure za odvijanje redosleda procesa).
Model: aproksimacija realnog sistema koja najpribliţnije predstavlja
tokove procesa, funkcionisanje i/ili druge relevantne atribute realnog
sistema; formalni i funkcionalni modeli.
Optimalni nivo bezbednosti: prihvatljivi nivo bezbednosti koji se
odrţava rentabilnim sistemom zaštite ĉiji su troškovi potpuno izjednaĉeni
sa procenjenim potencijalnim gubicima koji mogu nastati kao rezultat
realizacije potencijalne pretnje i proboja sistema zaštite.
Optimalni sistem zaštite: definiše se najĉešće u odnosu na kriterijume
funkcionalnosti i troškova akvizicije/razvoja sistema zaštite, dobije se
kada su troškovi dodatnih mera zaštite IKT sistema, potpuno izjednaĉeni
sa procenjenim potencijalnim gubicima koji mogu nastati kao rezultat
realizacije potencijalne pretnje i proboja sistema zaštite.
OSI (Open System Interchange) - referentni model sistema otvorene
mreţne višeslojne arhitekture (definiše ga ITU - International
Telecommunication Union standard ITU X.200/ISO 7498 iz serije "X",
1994). Otvoreni sistem podrazumeva bilo koji hijerarhijski organizovan
raĉunarsko-komunikacioni sistem koji funkcioniše na principu zajedniĉki
dogovorenih pravila za komuniciranje sa ostalim otvorenim sistemima,
bez obzira na specifiĉnost hardvera i mreţnih karakteristika sistema.
Problemi raĉunarskih komunikacija u OSI referentnom modelu su
sistematizovani u sedam celina i predstavljeni sa sedam slojeva (nivoa):
fiziĉki, linijski, mreţni, transportni, sesijski i aplikacioni. Svaki sloj
obavlja specifiĉan i zaokruţen skup aktivnosti u okviru raĉunarskih
komunikacija.
Proaktivna zaštita: detekcija napada (incidenta) i adekvatan odgovor na
napade, zaštita od poznatih i nepoznatih ranjivosti sistema pre napada.
Sistem: integrisani skup ljudi, proizvoda i procesa koji obezbeĊuje
kapacitete (sposobnost) da zadovolji neku potrebu ili cilj; ili neki skup
stvari ili delova koji formiraju kompleks ili jedinstvenu celinu; skup
komponenti organizovanih da ispune specifiĉnu funkciju ili set funkcija:

- 270 -
ili interaktivna kombinacija elemenata, koja se posmatra u meĊusobnim
odnosu sa funkcijama.
Strategija proaktivne zaštite: koncept zaštite od dinamiĉki
promenljivih, kombinovanih pretnji na Internetu; kombinuje informacije
CIRT (Computer Incident Response Team) i CERT(Computer
Emergency Response Team) timova širom sveta u praćenju napada i
ranjivosti sistema, savremenu tehnologiju za proaktivnu zaštitu od
poznatih i nepoznatih pretnji i procesni pristup pojednostavljene zaštite
IKT sistema.
Strategija reaktivne zaštite: koncept zaštite planiran i implementiran da
reaguje na poznate napade.

- 271 -
5. LITERATURA

1. American Bar Association, Section of Science &Technology

Law, Privacy & Computer Crime Committee, International
Strategy for Cyberspace Security,
www.abanet.org/abapubs/books/cybercrime, 2003
2. Australian Communications-Electronic Security Instruction
33 (ACSI 33), www.acsi.com , 2002.
3. Bjork Fredrik, Security Scandinavian Style-Interpreting the
practice of managing information security in organizations,
Stockholm University, Rozal Institute of Technology, 2001.
4. CERT, http://www.cert.org/advisories, 2003.
5. Dr. Rayford B. Vaughn, Jr, A practical approach to sufficient
INFOSEC, Mississippi State University, Department of
Computer Science, vaughn@cs.msstate.edu, 2002.
6. Glenn Fourie, The evolution of the information Security
mindset: a hypothesis of Stages of individual and enterprise
Security maturation, www.sans.com, May 8, 2002.
7. Grance T., Hash J., Stevens M., Security Considerations in
the Information System Development Life Cycle , NIST SP
800-64, http://www.nist.gov/publications, juni 2004.
8. http://www.cve.mitre.org.
9. http://www.isecom.org/projects/osstmm.htm.
10. ISO/IEEC 13335 - Guidelines for the management of IT
Security, , http://www.iso.13335.org, 2003.
11. ISS, Dynamic Threat Protection™ : A New Definition for
Information Security, http://www.iss.org, 2005.
12. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII.
decembar, 2005.
13. OECD – Guidelines for the Security of information systems
and Networks, http://www.oecd.org, 2000.
14. RFC 2196, Site Security handbook,
http://www.icann.rfcwditor.org, 1997.
15. Stoneburner G., Hayden C. and Feringa A., Engineering
Principles for Information Technology Security (A Baseline
for Achieving Security), NIST SP 800-27,
http://www.nist.gov/publications, 2004.
16. Stremus P., ISS IDC Security, IDC simpozijum,
pstremus@iss.net, Beograd 2006.

- 272 -
17. The Canadian Handbook on Information Technology (IT)
Security, www.canada.gov.itsec.com, 1999.

- 273 -
3. PROCESI I PROCEDURE ZAŠTITE

0. UVOD

Po završetku ovog poglavlja razumećete:

- značenje pojmova procesa i procedura zaštite

- ulogu procesa i procedura u kontekstu sistema zaštite
- faktore zrelosti i stabilnosti procesa zaštite
- praktični metodi za poboljšavanje procesa zaštite

Procesi zaštite definišu kako se prenose zahtevi Politike zaštite i

zahtevi koji proistiĉu iz rezultata procene rizika u stabilne procese, koji
se brzo mogu adaptirati na promene svake vrste. Retko kada specijalisti
zaštite poĉinju razvoj programa zaštite i projektovanje sistema zaštite od
samog poĉetka. Uglavnom je u praksi sluĉaj poboljšavanja postojećih
procesa zaštite, odnosno reinţenjering postojećeg sistema zaštite.

Poboljšavanje procesa zaštite odvija se u nekoliko faza. Glavne promene

(modifikacije) u sistemu zaštite predviĊaju se u ranoj fazi projektovanja i
treba ih planirati u formi projekta. Treba uspostaviti sistem kontrola
osnovne zaštite (baseline) za poboljšanje, koje su optimalne i rentabilne
za dati IKT sistem i obezbediti da su postojeće procedure zaštite dobro
shvaćene i korektno dokumentovane. Kada se jednom dostigne stabilan
nivo procesa dalje aktivnosti liĉe pre na fino podešavanje nego na
znaĉajnije promene, odnosno, postaje pre neprekidna aktivnost nego
projektno orijentisan proces.

Poboljšanje celog procesa zaštite je kompleksna aktivnost. Da bi se

problem pojednostavio proces se dekomponuje u sastave procedure i vrše
se poboljšanja tih procedura. Procedure koje su meĊusobno jako zavisne,
grupišu se i izvršavaju po prioritetima prema broju procedura u grupi i
teţini poznatih elemenata, a teţište poboljšavanja usmerava se na
najproblematiĉnije procedure. Ovakav pristup daje najbrţe rezultate i
oslobaĊa resurse za poboljšanje drugih manje problematiĉnih procedura.

- 274 -
1. PROCESI I PROCEDURE ZAŠTITE

1.1. Procesi zaštite

U opštem sluĉaju, proces se moţe definisati kao skup aktivnosti

(baziĉne prakse), koje se izvršavaju radi postizanja odreĊene namene,
imaju jedinstven cilj, poĉetak i kraj, a mogu se izvršavati iterativno,
rekurzivno i/ili konkurentno. Procesu se mogu pripisati razliĉiti atributi
na osnovu kojih proces moţe biti, [2], [4]:

1. Izvršen – stvarno izvršen (implementiran);

2. Upravljan – izvršava se u skladu sa politikom zaštite,
monitorisan, kontrolisan, revidiran, postiţe planirane ciljeve i
konzistentnost performansi,
3. Definisan – upravljan, skrojen od standardnih procesa
organizacije, detaljno opisan kroz procedure, rigorozno izvršavan,
povećava vrednost proizvoda rada,
4. Kvantitativno upravljan – dobro definisan, statistiĉki
kvantitativno kontrolisan u toku projekta, obezbeĊuje predviĊanje
performansi procesa, (merljiv, ponovljiv) omogućava primenu
sistema merenja, testiranje i ponovljivost,
5. Optimalan (adaptivno upravljan) – prati promene okruţenja da
postigne relevantne tekuće i projektovane poslovne ciljeve

Dakle, optimalan proces je efektivan i efikasan (kvalitetan, zreo)

kvantitativno upravljan, ima jasno definisane granice i obim, resurse
(ljudske, materijalne i vremenske), efikasno upravljanje, kontrolu rizika i
kontrolu procesa i daje oĉekivane izlazne rezultate. Standard modela
sazrevanja procesa zaštite (SSE CMM) obezbeĊuje metriĉki sistem koji
se zasniva na vrednovanju teţinskim faktorima navedenih atributa
procesa zaštite i koristi se u metodologiji vektora zaštite (S-vektora) za
merenje nivoa zaštite web aplikacija, kao i za merenje progresa u razvoju
programa zaštite i poboljšanja procesa zaštite. Sa aspekta sistema
kvaliteta i metrike sazrevanja relevantan je sledeći skup atributa procesa:

1. kapacitet procesa - opseg oĉekivanih rezultata izvršenog procesa,

2. mera izvršavanje procesa - skup stvarnih pokazatelja stepena
izvršavanja procesa,
3. zrelost procesa - mera do koje je specifiĉni proces eksplicitno
izvršen, upravljan, definisan, merljiv i kontrolisan i efektivan.

- 275 -
 4. stabilnost procesa – mera u kojoj je proces produktivan,
adaptivan i korisnički prihvatljiv; nivo zrelosti procesa direktno
odreĊuje nivo njegove stabilnosti.

Savremeni sistemi zaštite modeluju se kao procesi i projektuju na bazi

procesnog pristupa. Znaĉaj procesnog pristupa u projektovanju sistema
zaštite je višestruk:

 organizacija koja definiše i dokumentuje procese zaštite stavlja oblast

zaštitu podataka i informacija na isti nivo sa drugim relevantnim
procesima organizacije,
 procesni pristup pomaţe da se preusmeri paţnja sa neodmerene
primene tehnologije zaštite na sve mere i metode koje dovode do
smanjenja rizika,
 procesni pristup olakšava integraciju sistema zaštite sa postojećim
sistemom kvaliteta.

Integracija u sistem kvaliteta poţeljna je, jer oblast i dokumenta zaštite

imaju isti tretman kao druge vitalne poslovne oblasti i dokumenta
organizacije, a grupa za zaštitu koristi sve prednosti sistema za kontrolu
kvaliteta, ukljuĉujući standardnu proceduru kontrole i revizije
dokumenata od strane nezavisnog kontrolora (auditora) zaštite. Znaĉajno
je da sistem kvaliteta podrţava proces zaštite, ali ne i obrnuto.

U tom kontekstu proces zaštite moţe se smatrati kao mehanizam koji

transformiše skup ulaznih podataka i informacija sistema zaštite u skup
izlaznih rezultata (podataka i informacija), (Sl. 1.1.a). Ako se za proces
uzme da je reaktivni sistem zaštite, onda su, [7]:

1. Ulazni podaci i informacije:

 nebezbedni (nezaštićeni) podaci i informacije (sistem),
 poznate pretnje,
 poslovna strategija organizacije i
 normativni zahtevi (zakona, regulativa, standarda).
2. Izlazni rezultati:
 bezbedni (zaštićeni) podaci i informacije (sistem),
 obuĉeno osoblje i
 dokumentacija zaštite.

- 276 -
 Poznate
pretnje
Obučeno
osoblje
Neobučeno
osoblje
Proces zaštite
=
Upravljačke aktivnosti
Zaštićeni podaci
+
Nebezbedni i sistemi
Procedure
podaci i sistemi
+
Dokumentacija procesa

Legalni i Dokumentacija
regulatorni zahtevi

Poslovna
strategija

Sl.1.1.a. Proces zaštite

U sistemskom inţenjerstvu proces se moţe definisati i kao integrator:

procedura i metoda koje definišu odnose izmeĊu zadataka procesa;
tehnologije (tehnika i alata) i ljudi, dobro osposobljenih, motivisanih i sa
odgovarajućim veštinama za izvršavanje zadataka procesa (Sl. 1.1.b).

Procedure i metodi
definišu odnose
izmedu zadataka

PROCES

Ljudi
sa veštinama, Tehnologija
obuceni, (tehnike i alati)
motivisani

Sl.1.1.a. Proces zaštite

Tekuća praksa zaštite ne sadrţi dobro definisane procese koje

organizacije mogu direktno koristiti za poboljšavanje inţenjerskih i
drugih aktivnosti u zaštiti. U praksi zaštite rezultati primene sistemskog
inţenjerstva ukazuju da se aktivnosti u zaštiti ĉešće smatraju odvojenom
celinom, nego integralnim delom ukupne aktivnosti na razvoju IKT
sistema. TakoĊe, definisani i šire prihvaćeni procesi zaštite obuhvaćeni sa
dva poznata standarda ISO/IEC 17799 (kontrole zaštite), [4] i ISO/IEC
21827 (SSE CMM- model sazrevanja procesa zaštite), [5], nisu u
potpunosti meĊusobno usaglašeni.

- 277 -
1.2. Generiĉki proces sistema zaštite

Implementacija i odrţavanje razumnog nivoa zaštite IKT sistema

moţe se samo obezbediti ako se sve komponente zaštite procesiraju na
planski i organizovan naĉin. Kvalitetna implementacija programa/sistema
IKT zaštite i kontrola njihove efektivnosti i efikasnosti zahteva dobro
koncipiran, kontrolisan i stabilan proces zaštite.

Generički proces zaštite poĉinje definisanjem bezbednosnih ciljeva i

uspostavljanjem procesa upravljanja zaštitom. Glavna funkcija
upravljanja zaštitom je da izradi i implementira koncept sistema IKT
zaštite. Kako je odrţavanje bezbednosti IKT sistema neprekidna
aktivnost, proces IKT zaštite regularno se vraća na koncept zaštite, tako
da omogućava neprekidnost procesa zaštite (Sl. 1.2), [6].

Iniciranje procesa zaštite:

- postavljanje zahteva/ciljeva zaštite
- uspostavljanje sistema upravljanja zaštitom

Izrada koncepta sistema zaštite:

- modelovanje (IS, arhitekture zaštite)
- izbor metodologije

Implementacija koncepta zaštite:

- analiza rizika
- izbor kontrola zaštite
- implementacija i integracija kontrola
- razvoj svesti i obuka
- sertifikacija/akreditacija (C&A) zaštite

Upravljanje konfiguracijom :
- nadzor i kontrola sistema zaštite
- odrţavanje sistema zaštite
- reinţinjering/reakreditacija...

Sl.1.2. Generiĉki proces IKT zaštite

- 278 -
Koncept (model) IKT zaštite nezamenljiv je za implementaciju
neophodnih kontrola zaštite.
Za odrţavanje kontinuiteta procesa zaštite treba sistematski primenjivati
sledeće korake:
– razviti i po potrebi aţurirati Politiku zaštite IKT sistema,
– izabrati i uspostaviti odgovarajuću organizacionu strukturu za
upravljanje IKT zaštitom,
– kreirati koncept IKT zaštite,
– implementirati kontrole zaštite,
– izvršiti obuku i razviti svest o potrebi zaštite,
– odrţavati sistem zaštite u operativnoj praksi.
1.3. Procedure zaštite
Proces sistema zaštite moţe se dekomponovati u skup procedura
koje proces sadrţi. Procedura zaštite je sekvencijalno izvršavanje
baziĉnih aktivnosti i zadataka. Procedura zaštite povezuje aktivnosti
zaštite, koje ĉini skup povezanih elementarnih radnji i odreĊuje redosled
izvršavanja aktivnosti i zadataka. Dakle, generiĉki proces sistema zaštite
potpuno je odreĊen koherentnim skupom: procedura zaštite,
dokumentacije zaštite i upravljačkih akcija, koje koordiniraju jedinstven i
koherentan rad svih delova celine.
Odnos procesa i procedura zaštite prikazan je na slici Sl.1.1.a i b, [7].

Proces zaštite normalno se dokumentuje kroz sastavne procedure koje se

opisuju u dokumentaciji zaštite. Pri tome treba koristiti zdravu logiku da
se smanji kompleksnost, izbegne nepotrebno ponavljanje i odredi nivo
detalja u svakom dokumentu zaštite.

U većini sluĉajeva najbolje je odrţavati minimalni obim dokumentacije

koristeći što manje teksta, a više grafikona, modela, kontrolnih upitnika
(ĉek listi), radnih tabela i sl., kao i pozivanjem na drugu literaturu, što
odrţava redundantnost informacija na minimumu. Na taj naĉin
pojednostavljuje se proces odrţavanja sistema zaštite i povećava
verovatnoća da će dokumenta biti stvarno proĉitana i korektno korišćena.

- 279 -
2. STABILNOST PROCESA ZAŠTITE

Stabilan proces zahteva da se ispune tri osnovne oblasti zahteva za:

produktivnost, adaptivnost i korisničku prihvatljivost (Tabela T. 2.1), [7].

PRODUKTIVNOST: da dizajn procesa obezbeĊuje visok nivo

produktivnosti.
ADAPTIVNOST da je proces sposoban da se prilagodi
Zahtevi za
promenama okruţenja, odnosno da je dizajn procesa fleksibilan i
stabilan
skalabilan.
proces
KORISNIĈKA PRIHVATLJIVOST: da je proces u skladu sa
kulturom organizacije i da dizajn procesa zadovoljava krajnjeg
korisnika.

T. 2.1. Zahtevi za stabilan proces

2.1. Produktivnost.

Produktivnost ili efektivnost procesa je najkritiĉnija oblast i ako u

njoj proces ne ispuni oĉekivane rezultate smatra se neuspešnim. Uzroci
manje produktivnosti procesa zaštite su razliĉiti, ali se mogu svrstati u
ĉetiri grupe razloga:

 neodgovarajući bezbednosni ciljevi kontrola zaštite,

 nerealni ciljevi servisa zaštite,
 neefikasni kontrolni mehanizmi,
 slabo dizajniran tok (izvršavanja) procesa.

Neodgovarajući bezbednosni ciljevi kontrola zaštite utiĉu negativno na

produktivnost, angaţujući resurse koje bi u drugim aktivnostima dale
bolje rezultate u ublaţavanju rizika. Bezbednosni cilj kontrole zaštite
oĉigledno je neadekvatan ako: znaĉajno ne smanjuje rizik, ne
zadovoljava normativne zahteve ili ne obezbeĊuje rentabilno rešenje za
smanjenje rizika.

Drugim reĉima, malo koristi implementacija ekstremno kvalitetne

kontrole u jednoj oblasti procesa zaštite, ako se ostave ranjivosti u
drugim oblastima.
Nerealni ciljevi servisa zaštite mogu presudno uticati na efektivnost
servisa. Dobar primer je servis i procedura autorizacije i logiĉke kontrole

- 280 -
pristupa. Ako oĉekivanja zaposlenih premašuju kapacitete administratora
korisniĉkih naloga, dolazi do zagušenja i blokiranja rešavanja zahteva.
Tada zaposleni ĉešće kontaktiraju administratora za zaštitu koji troši
vreme na rešavanje individualnih zahteve i dalje degradira isti servis.

Neefikasni kontrolni mehanizmi su oni koji se regularno ne nadgledaju,

brzo zastarevaju i zato postaju neefikasni. Na primer, digitalno potpisan
e-mail ne dodaje novu vrednost dokumentu, sve dok ovlašćena strana i
transakciji ne verifikuje potpis.

Slabo dizajniran tok procesa i neodgovarajuće dodeljivanje odgovornosti

ĉesto je uzrok problema u procesima zaštite. Na primer, ĉesta greška
nastaje kada se nekom višem menadţeru pripiše odgovornost za
odobravanje zahteva za bezbednosno relevantne promene u sistemu, a
poznato je da oni retko redovno i na vreme izvršavaju taktiĉke i
operativne zadatke.

2.2. Adaptivnost

Adaptivnost procesa zaštite odreĊena je sposobnošću procesa da se

primenjuje fleksibilno u arhitekturi sistema zaštite i da omogućava
skalabilnost (faznu nadogradnju, proširivanje, poboljšanje) procesa.
Glavni uzroci nedovoljne adaptivnosti procesa su:

 suviše specifiĉni, a nedovoljno generiĉki dizajn procesa,

 nedovoljno se koriste uloge i odgovornosti,
 nedovoljno se obraća paţnja na kompenzujuće (univerzalne) kontrole
zaštite i
 ne ugraĊuju se realno oĉekivani (potencijalno novi) zahtevi zaštite u
dizajn procesa.

Specifični i generički zahtevi: Iako je većina procedura kontrola zaštite

dizajnirana za generiĉke zahteve, ĉesto se dobro uklapaju u realni
kontekst. Tipiĉan primer je procedura za upravljanje vanrednim
dogaĊajem. MeĊutim, ako su procedure zaštite dizajnirane za specifiĉan
sistem i okruţenje, teško da se moţe iskoristiti kao kompenzaciona
kontrola na nekom drugom mestu u arhitekturi sistema zaštite.
Kompenzaciona kontrola je ona koja se moţe koristiti za kompenzaciju
ranjivosti bilo gde u sistemu zaštite.

- 281 -
Uloge i odgovornosti: Procedure koje koriste koncept uloga fleksibilnije
su od onih koje reflektuju organizacionu strukturu, što je vaţno za veće
organizacije gde su promene ĉeste.

Ugradnja potencijalnih zahteva: Dizajniranje procedura i kontrola za

individualni IKT sistem, ne uzimajući u obzir promene sistema,
tehnologija i okruţenja, znaĉajno redukuju mogućnost nadogradnje
procesa i korišćenja kompenzacionih kontrola.

2.3. Korisniĉka prihvatljivost

Efektivan i efikasan (uspešan) proces je samo onda ako je

usklaĊen sa zahtevima krajnjeg korisnika i dizajniran tako da se uklapa u
kulturu rada organizacije. Procesi koji ne uzimaju u obzir zahteve
uĉesnika verovatno će biti zapostavljeni ili slabo korišćeni. Na dizajn
procesa sa aspekta korisniĉke prihvatljivosti presudno utiĉu sledeći
relevantni faktori: kompleksnost,
zavisnost od skupa specifičnih znanja i veština i psihološki aspekt.
Kompleksnost: Smanjenje kompleksnosti procesa dovodi do boljeg
razumevanja, a razumevanjem se isti bolje izvršava.

Specifična znanja i veštine: Samo sa dobrim razumevanjem

bezbednosnih procesa korisnici mogu prepoznati neobiĉne pojave i
nenormalne dogaĊaje u sistemu. Korisnici mogu postići razumevanje
sintakse i semantike sloţenijih procesa, ali za razumevanje normalnog
ponašanja tih procesa, kao i za upravljanje rizicima za te procese
zahtevaju se ekspertska znanja.

Psihološki aspekt: Osnovni psihološki problem je što odreĊene aktivnosti

zaštite mogu prerasti u rutinu, a poznato je da rutinski zadaci teško
motivišu korisnike da ih korektno i konzistentno izvršavaju, što moţe
presudno uticati na efektivnost procesa zaštite.

- 282 -
3. POBOLJŠAVANJE PROCESA ZAŠTITE

3.1. Metodi za poboljšavanje procesa

Praksa je potvrdila da mnogi procesi zaštite ne proizvode

oĉekivane rezultate i pored primene solidne metodologije. Poboljšavanje
procesa je klasiĉni cilj upravljanja kvalitetom. Postoje brojni metodi za
ovo. Iskustvo iz prakse administracije sistema zaštite kljuĉni je ulazni
parametar za poboljšavanje procesa zaštite. Korišćenje neke
metodologije za poboljšanje produktivnosti, adaptivnosti i korisniĉke
prihvatljivosti moguće je, ali više odgovara objektno orijentisani
strukturni pristup za identifikaciju problema i izvršavanje modifikacije,
zato što promena operativnih procedura moţe ukljuĉivati znaĉajan rizik.

Efektivan metod za poboljšavanje procesa zaštite odvija se kroz sledeće

korake:

 Razumeti i dokumentovati tekući proces;

 Dekomponovati proces u skup sadrţanih procedura i pomoćnih
mehanizama;
 Odrediti redosled procedura prema prioritetu potrebe za
poboljšanjem;
 Identifikovati ciljne zahteve za svaku proceduru;
 Planirati faznu implementaciju kao seriju postupnih (inkrementalnih)
poboljšanja;
 Implementirati i upravljati zavisnostima izmeĊu procedura.

Prvi korak poboljšavanja bilo kojeg procesa je razumevanje onoga što je

instalirano. Kada se proces potpuno shvati, tek onda vredi verifikovati da
li je korektno dokumentovan, pošto je ova dokumentacija osnova za dalju
modifikaciju. Proces se dokumentuje kroz brojne procedure, koje
potencijalno podrţava jedan ili više alata (mehanizama, protokola).
Procedure se zatim rangiraju po redosledu stabilnosti na bazi broja i
teţine stanja poznatih elemenata. Ovo je vaţan korak pošto poboljšanje
procesa zahteva vreme, pa je zato vaţno koncentrisati se na one oblasti
procesa koje izazivaju najveće probleme. Kada se odrede prioriteti
poboljšavanja procedura, moţe poĉeti rad na identifikovanju metoda
poboljšavanja. U sluĉajevima gde ima mala meĊuzavisnost izmeĊu
procedura, poboljšavanje se najbolje postiţe tretiranjem svake procedure
odvojeno. Ako su zavisnosti jake, lakše je poboljšavati odnosnu grupu

- 283 -
procedura u isto vreme. U oba sluĉaja treba proveriti konzistentnost
poboljšavanja procesa. Planiranje implementacije kroz seriju
inkrementalnih poboljšavanja ograniĉava rizik, jer se u sluĉaju
pogrešnog koraka lakše vratiti nazad sa malim, nego sa velikim
pomakom. Ovaj pristup treba primenjivati na poboljšavanje
produktivnosti, adaptivnosti i korisniĉke prihvatljivosti procesa zaštite.

Za praktiĉnu proveru navedenog metoda za poboljšanje procedura zaštite

razvijena je Vežba GII P3A sa zadatkom grupnog rada studenata na
poboljšanju procedure za autorizaciju prava pristupa u servisu logiĉke
kontrole pristupa.

3.2. Poboljšavanje produktivnosti

Produktivnost je mera u kojoj se oĉekivani izlaz moţe postići sa

fiksnim skupom resursa. Što je veća produktivnost, proizvodi se veći
izlazni rezultat. Glavni faktori koji utiĉu na produktivnost-Pr su:
efektivnost-Ee, efikasnost-Ei i vremenski ciklus (ponovljivost)-Po, pa je:

Pr = f (Ee, Ei, Po)

gde Pr = f(x) znaĉi da je Pr funkcija od x, a ne preciznu matematiĉku

relaciju.

Efektivnost („činjenje pravih stvari―) odraţava u kojoj meri neki proces

ispunjava postavljene bezbednosne ciljeve. Efektivan bezbednosni proces
je onaj koji smanjuje rizik u skladu sa oĉekivanjem (ni previše ni
premalo).

Efikasnost („rentabilno izvršavanje pravih stvari―) je mera troškova

proizvodnje izlaznih rezultata u odnosu na ulaz, pa će visoko efikasan
proces proizvesti oĉekivani izlazni rezultat po najniţoj ceni.

Ponovljivost (vremenski ciklus procesa) je mera brzine sa kojom se moţe

proizvesti izlazni rezultat. Poboljšanjem vremenskog ciklusa
(smanjenjem perioda ponavljanja procesa) smanjuje se kašnjenje izmeĊu
unosa ulaznih podataka i proizvodnje izlaznih rezultata.

Sva tri navedena atributa su meĊuzavisna. Na primer, nema smisla

tvrditi da je neki „proces efikasan, ali je neefektivan―.

- 284 -
3.2.1. Poboljšavanje efektivnosti procesa

Poboljšavanje efektivnosti procesa je sinonim za uklanjanje svake

aktivnosti koja ne dodaje novu vrednost datom procesu, što znaĉi
uklanjanje svake aktivnosti koja ne doprinosi transformaciji ulaznih
parametara u izlazne rezultate. Odluĉujući faktor za procenu koja
aktivnost dodaje vrednost, a koja ne, najĉešće je zdrav razum. Otvorena
su pitanja koji nivo dokumentacije se zahteva za smanjenje rizika na
optimalan naĉin, kako definisati sastavne komponente sistema zaštite ili
proceniti nivo obuĉenosti u zaštiti. Pre implementacije specifiĉnih
kontrola zaštite za ublaţavanje rizika, treba razmotriti sve opcije. Ako su
procedure kontrole skupe, prihvatljiva opcija je da se rizik prihvati, ili
prenese na poverljivog (TTPS) provajdera zaštite.

Prvi korak u poboljšavanju efektivnosti postojećih procedura zaštite je da

se proveri da li se rizik smanjuje na odgovarajući naĉin. Data procedura
treba da smanjuje rizik na prihvatljivi nivo. Poznato je da organizacije
mogu implementirati program/sistem zaštite na osnovu, [7]: politike
zaštite, analize rizika i/ili najbolje prakse zaštite.

Organizacije koje razvijaju program/sistem zaštite na osnovu politike ili

najbolje prakse zaštite, mogu poboljšati efektivnost procedura
analizirajući ih na ovaj naĉin. MeĊutim, implementacija na osnovu
najbolje prakse zaštite nije optimalna, jer je najbolja praksa namenjena za
idealan nivo zaštite i implementaciju najboljih kontrola zaštite u datom
okruţenju, a većina korisnika ţeli rešenje zaštite u konkretnom okruţenju
i sa što manje troškova, što je glavni kriterijum optimalnosti
programa/sistema zaštite.

3.2.1. Poboljšavanje efikasnosti procesa

U skladu sa definicijom smanjenja troškova zaštite, ne znaĉi da je

brţi proces nuţno i efikasniji. Za poboljšavanje efikasnosti procesa mere
poboljšavanja se klasifikuju na: organizacione, logičke i tehnološke
(odnose se na alate zaštite).

Organizacione mere poboljšavaju efikasnost promenom naĉina na koji

procedure utiĉu na korisnike, zbog ĉega imaju veliki uticaj na korisniĉku
prihvatljivost, što se mora uzeti u obzir u dizajniranju procesa.

- 285 -
Primer organizacionih metoda za povećavanje efikasnosti ukljuĉuje:

 postavljanje realnih bezbednosnih ciljeva,

 praćenje korisniĉkih oĉekivanja,
 odreĊivanje prioriteta,
 smanjenje zavisnosti od skupa specifiĉnih znanja i veština,
 adekvatno pripisivanje odgovornosti.

Postavljanje realnih ciljeva i postizanje sporazuma o nivou servisa (SLA-

Service Level Agreement) sa korisnicima, poboljšava efikasnost
eliminisanjem aktivnosti nepotrebnog praćenja ponašanja krajnjih
korisnika. Umesto toga administrator moţe posvetiti više vremena
kljuĉnim procesima, a manje za rad sa nezadovoljnim korisnicima. Kada
se definišu ciljevi i uspostave nivoi servisa, tada ima smisla planirati
akcije za ekstremne situacije, kao što je privremeno odsustvo više
administratora u isto vreme. Jedan naĉin rešavanja ovog problema je
odreĊivanje prioriteta izvršavanja aktivnosti i definisanje naĉina
bezbednog rada (safe mod) koji se usmerava na izvršavanje najvaţnijih
servisa. SLA treba da obezbedi pod kojim se uslovima ovaj mod rada
uvodi i kako se uvodi. OdreĊivanje prioriteta izvršavanja procedura koje
sadrţi proces, obezbeĊuje optimalno korišćenje raspoloţivih resursa.
Zato je odreĊivanje prioriteta, tehnika organizacionog poboljšavanja,
pošto se odnosi na to kako ljudi interaktivno rade sa procedurama.
Korišćenje resursa nije u pitanju u normalnim uslovima rada, ali postaje
vaţno pitanje u uslovima povećanog obima aktivnosti, ili kada nema
dovoljno resursa. Na isti naĉin unutar procedura moguće je odrediti
prioritete izvršavanja aktivnosti. Na primer, u uslovima velikog
opterećenja obiĉno su prioritetniji zahtevi za proizvodnju, od onih za
razvoj.

Smanjenjem zavisnosti procesa od skupa specifiĉnih veština povećava se

efikasnost, zato što je lakše i jeftinije angaţovati neobuĉeno osoblje. U
ovom sluĉaju korisno je razviti veštine tamo gde povećavaju vrednost.
TakoĊe, nije efikasno zahtevati da uprava ukine neke aktivnosti koje nisu
neophodne, zato što je menadţer obavezan da prethodno proveri da li se
ta aktivnost izvršava korektno. U stvari, gde je nivo ukidanja aktivnosti
oĉigledno neodgovarajući, postoji rizik da menadţer neće pravilno
shvatiti zadatak, što moţe dovesti do gubitka kontrole procesa.

- 286 -
Logiĉki metodi poboljšavanja efikasnosti usmereni su na poboljšavanje
logiĉkog dizajna procedura, što ukljuĉuje optimalni dizajn procesa u
pogledu korišćenja resursa i dizajna procesa u kojem je obim
individualnih procedura dobro kontrolisan, a nepotrebna preklapanja
procedura smanjena na minimum. Na primer, procedura eskalacije
(trajanja) procesa povećava efikasnost obezbeĊivanjem tretmana
problema od strane osoblja sa odgovarajućim nivoom ovlašćenja.
Administratoru treba nekoliko ĉasova da obezbedi dozvolu za gašenje
servera, a menadţeru svega nekoliko minuta. Ovaj metod se takoĊe
koriste za poboljšanje dizajna individualnih procedura, korigovanjem
grešaka u logiĉkom toku, što pak rezultira u povećanju troškova.

Konaĉno, efikasnost se ĉesto moţe poboljšati korišćenjem razliĉitih alata

za dobijanje istih ili boljih rezultata od korišćenja postojećih alata, što se
uglavnom postiţe automatizovanjem manuelnih procesa a oĉigledno je u
sluĉaju administrativne procedure. Kreiranje korisniĉkih naloga i
uspostavljanje podrazumevanih prava pristupa zahteva mnogo koraka i
vremena na nekim platformama. Programiranjem ovih aktivnosti
obezbeĊuje se znaĉajno povećanje produktivnosti.

3.2.2. Smanjenje ciklusa ponavljanja procedure

Vremenski ciklus ponovljivosti procedure je mera vremena

potrebnog da se proces izvrši (poĉne i završi), što je ekvivalentno brţem
izvršavanju procedure i predstavlja povećanje produktivnosti. Ovo
poboljšavanje posebno je vaţno u proizvodnoj industriji gde dugi ciklusi
isporuke dovode do nezadovoljstva kupaca, povećanja troškova i.t.d. U
sistemu zaštite smanjenje ciklusa ponavljanja procedure najvaţniji je
instrument povećanja zadovoljstva korisnika što ne vaţi samo za rutinske
administrativne procese, nego i za procese razvoja i nabavke softvera.

Ako proceduru smatramo sekvencijalnim izvršavanjem baziĉnih praksi

(aktivnosti, zadataka), moţemo poboljšati vreme ciklusa ponavljanja:
uklanjanjem zadataka koji ne dodaju nove vrednosti, bržim izvršavanjem
zadataka, ili smanjenjem kašnjenja izmeĎu zadataka. Prvo je diskutovano
u povećanju efikasnosti. Povećavanje brzine izvršavanja moţe se postići
automatizacijom. Povećavanje broja resursa takoĊe je opcija, ali
povećava troškove. Mada ovo moţe biti jedino rešenje za neke vremenski
kritiĉne procedure. Za mnoge organizacije smanjenje kašnjenja izmeĊu
zadataka daje najveću mogućnost za poboljšavanje i ĉesto se moţe

- 287 -
postići poboljšanjem toka procesa. Potencijalni uticaj mera za smanjenje
vremenskog ciklusa ponavljanja procesa mora se paţljivo razmatrati pre
implementacije. Ako procedure postanu opterećenje, verovatno je da će
motivacija korisnika brzo opasti.

3.3. Poboljšavanje adaptivnosti

Adaptivnost-A je sposobnost procesa da se brţe prilagodi i olakša

modifikaciju procesa na promene okruţenja. Sposobnost adaptacije
procesa odreĊuje se atributima fleksibilnosti-F i skalabilnosti-S procesa.
Fleksibilnost je sposobnost asimilacije novih funkcionalnih i
bezbednosnih zahteva, a skalabilnost je sposobnost da proces moţe
prihvatiti povećan obim:

A = f(F, S)

gde A= f(x) oznaĉava da je A funkcija od x, a ne formalni matematiĉki

izraz.

3.3.1. Poboljšavanje fleksibilnosti

Poboljšavanje fleksibilnosti procesa obuhvata modifikaciju

procesa na bilo koji naĉin koji olakšava ukljuĉivanje novih promena u
funkcionisanju. Jedan od najlakših puteva za povećanje fleksibilnosti je
smanjenje kompleksnosti. Ovo jednostavno odraţava ĉinjenicu da je lakše
razumeti uticaj promena u jednostavnijem sistemu nego u kompleksnom
sistemu. U skladu sa ovim principom, dizajn procesa treba da koristi
princip modularnosti. Procedure treba da imaju ograniĉene i vrlo
definisane obime, meĊuzavisnost procedura da se drţi na minimumu,
kontrola toka izmeĊu procedura da bude što je moguće više
standardizovana, a broj izuzetnih sluĉajeva koje treba rešavati
minimalan. TakoĊe, specifiĉne procedure koje se oslanjaju na
funkcionalnost posebnih sistema, treba zameniti generiĉkim
procedurama, gde god je moguće.

- 288 -
3.3.2. Poboljšavanje skalabilnosti

Skalabilnost je kljuĉno pitanje u visoko distribuiranom okruţenju,

gde su standardne procedure kao što su autorizacija i kontrola pristupa,
analiza logova i upravljanje ranjivostima, koje potencijalno treba izvršiti
za stotine i više platformi, kompleksne i vremenski zahtevne za
realizaciju.

Vaţna tehnika za upravljanje skalabilnosti ukljuĉuje i odreĊivanje

prioriteta za izvršavanje i isporuku rezultata i upravljanje gradacijom
prava pristupa.Obe tehnike postiţu skalabilnost po neku cenu. U prvom
sluĉaju, procedure postaju skalabilnije, koncentrišući se na one rezultate
koji najviše povećavaju vrednost. Na primer, procedura analize log
datoteka moţe se napraviti skalabilnom odreĊivanjem prioriteta i
proaktivnom kontrolom onih logova koji najviše doprinose smanjenju
rizika. Sliĉno, procedure za detekciju i otklanjanje ranjivosti mogu se
napraviti skalabilnijim, koncentrišući se na ranjivosti srednjeg ili visokog
rizika. Ovaj se kompromis pravi na bazi procene rizika, a omogućava
upravljanje sa više sistema po cenu ignorisanja ranjivosti niskog rizika.

Sliĉna argumentacija primenjuje se kada se menja granulacija kontrolnih

mera za povećanje skalabilnosti. Mehanizmi za kontrolu pristupa klasiĉni
su primeri u ovoj oblasti. Odrţavanjem granularnih prava pristupa za
brojne datoteke i stotine zaposlenih jasno da je neizvodljivo. Zbog toga
se i subjekti i objekti sistema kojima subjekti pristupaju, svrstavaju u
grupe u većini sistema.

MeĊutim, za većinu srednjih i velikih organizacija ova tehnika još uvek

moţe biti nedovoljna za izvršavanje stvarne kontrole i moţe se zahtevati
dalji nivo apstrakcije. Osnovna ideja ovog pristupa je da, iako je
granularnost ţrtvovana, stvarni nivo kontrole raste, zbog porasta
skalabilnosti procesa u celini.

- 289 -
3.4. Poboljšavanje korisniĉke prihvatljivosti

Na korisničku prihvatljivost-Kp utiĉe niz razliĉitih faktora,

ukljuĉujući već pomenute. Na primer, zaposleni verovatno neće biti
motivisani da uĉestvuju u procesu koji je oĉigledno neefikasan i mogu se
osećati frustrirano kada su procesi neefektivni. Na korisniĉko prihvatanje
procedura jako utiĉu kulturološka iskustva-Ki, nivo razumevanja
kompleksnosti-Ko i psihološki faktori-Pf.

Kp = f(Ki, Ko, Pf),

gde Kp=f(x) oznaĉava da je Kp funkcija od x, a ne formalni matematiĉki

izraz.

3.4.1. Kulturološki uticaj

Poznato je da kultura ima glavni uticaj na korisniĉku

prihvatljivost promena svake vrste. Primer ovog fenomena su brojna
propala udruţivanja meĊunarodnih organizacija, zbog nemogućnosti
prevazilaţenja kulturoloških razlika.

Moćna tehnika za uvoĊenje znaĉajnih promena je ona koja dopušta da

zaposleni sami uvode proces promena. Osnovna ideja je da se onima koji
izvršavaju tekuću proceduru obezbedi pomoć u identifikovanju zahteva i
rešenja. Iako ovo ponekad zahteva dosta rada (objašnjenja i instrukcija),
velika je verovatnoća da će konaĉan rezultat biti trajan. OdreĊeni nivo
otpora promenama neizbeţan je, ali u nekoj meri i poţeljan, zato što
primorava one koji uvode promene da dobro opravdaju promene u
odnosu na druga rešenja i postojeći model. Treba imati na umu da otpor
promenama deluje u oba pravca. Kako se zaposleni opiru promenama
tako i oni koji ih uvode nerado menjaju svoje predloge. Gde god je
moguće, najbolji pristup je uvoĊenje sitnih promena na regularan naĉin,
obezbeĊujući dobru pripremu zaposlenih za svaku promenu. Ovim se
korisnici postepeno prilagoĊavaju novom naĉinu izvršavanja procedura, a
izbegavaju se drastiĉne promene koje najĉešće demotivišu korisnike.

- 290 -
3.4.2. Smanjenje kompleksnosti

Intuitivno kompleksnost je barijera za korisniĉku prihvatljivost: sve

što je u ţivotu nerazumljivo tome se ne veruje, a nema razloga da je
zaštita izuzetak od ovog pravila. Za poboljšanje procesa kompleksnost je
vaţna u dve odvojene oblasti:

 dizajniranju (projektovanju) samog procesa zaštite i

 obuci zaposlenih (naĉinu prenošenja postavljenih ciljeva i dizajna
procesa zaposlenim).

Brojne procedure iz softverskog inţenjerstva mogu se primeniti na

probleme pojednostavljivanja dizajna procesa. Principi dizajna koji se
koriste za smanjenje kompleksnosti softvera, kao što su deljenje na
particije, hijerarhijska struktura i modularnost, posebno se koriste u ovoj
oblasti. Zaista, mera kompleksnosti koja se dugo koristi u softverskom
inţenjerstvu, kao što je ciklometrijski broj moţe se, takoĊe, koristiti za
merenje kompleksnosti modela procesa. MeĊutim, u praksi je retko
potrebno raĉunati kompleksnost da bi se ona izmerila, a odliĉni rezultati
se postiţu sledeći zdravu logiku. Na primer, broj taĉaka odluĉivanja u
proceduri dobra je indikacija njene kompleksnosti.

Naţalost, ĉak i kada su procesi zaštite dobro dizajnirani, moderne tehnike

zaštite informacija nisu lako dostupna za neupućene, a eksperti zaštite
koriste sloţeni reĉnik za opisivanje problema i rešenja u zaštiti. Deo
problema smanjenja kompleksnosti je obuka i naĉin na koji se
informacije prenose korisnicima. Izbegavanje struĉnih izraza, izrada i
odrţavanje kratke, konkretne i jasne dokumentacije mnogo doprinose
smanjenju kompleksnosti same dokumentacije zaštite. Jednostavni alati
kao što su dijagrami toka i kontrolne (ĉek) liste mnogo pomaţu u ovoj
oblasti, posebno kada ih prate objašnjenja i primeri koji su poznati
ĉitaocima.

- 291 -
3.4.3. Uticaj psiholoških faktora

Mera u kojoj se ljudi veţu za dobijene zadatke zavisi od brojnih

faktora, ukljuĉujući sposobnost izvršavanja zadataka i liĉnu
zainteresovanost za te zadatke. Ako je sposobnost izvršavanja zadataka
korisnika znatno iznad ili ispod zahtevanog standarda, motivacija će
verovatno biti niska. U prvom sluĉaju nedostatak motivacije nastaje zbog
neprekidnih neuspeha da se postigne zahtevani standard izvršavanja, a u
poslednjem sluĉaju zbog nedostatka izazova za izvršavanje aktivnosti.
Oblast personalne zaštite i aktivno upravljanje radnim zadacima,
obezbeĊuju da zaposleni primaju dovoljno raznolike i stimulativne
zadatke koji su u opsegu njihovih sposobnosti i koji povećavaju
motivaciju i produktivnost. Efikasan naĉin da se ovo postigne je
korišćenje metoda progresivnog sazrevanja procesa (SSE CMM), [8],
kojim se identifikuju posebne oblasti aktivnosti i relevantni skup
potrebnih aktivnosti od interesa za zaposlene. Zadatke treba planirati na
sliĉan naĉin kako se planira obuka i obrazovanje u zaštiti. Korisna
tehnika je regularno rotiranje uloga i odgovornosti u zaštiti.

- 292 -
4. REZIME

Savremeni sistemi zaštite modeluju se kao procesi. U tom

kontekstu proces se moţe smatrati kao mehanizam koji transformiše skup
ulaznih podataka i informacija u skup izlaznih rezultata (podataka i
informacija). U procesu sistema zaštite ulazni podaci i informacije su:
nebezbedni podaci i informacije, poznate pretnje, poslovna strategija
organizacije, zakonski i regulatorni zahtevi. Izlazni rezultati procesa
zaštite su: bezbedni podaci i informacije i sistemi, obuĉeno osoblje,
dokumentacija zaštite.

Procesi zaštite definišu kako se prenose zahtevi Politike zaštite i zahtevi

koji proistiĉu iz rezultata upravljanja rizikom u stabilne procese koji su
efektivni, korisniĉki prihvatljivi i brzo se mogu adaptirati na promene
svake vrste. Retko kada specijalisti zaštite poĉinju projektovanje sistema
zaštite od samog poĉetka. U praksi je sluĉaj poboljšavanja procesa
zaštite, odnosno reinţenjeringa postojećeg sistema zaštite.

Proces zaštite ĉini: skup procedura, dokumentacija zaštite i upravljaĉke i

koordinirajuće akcije koje su potrebne da svi delovi rade koherentno.
Korišćenje procesnog pristupa olakšava integraciju sistema zaštite sa
postojećim sistemom kvaliteta, što je poţeljno, jer tada oblast zaštite ima
isti tretman kao druge funkcionalne oblasti organizacije.

Stabilnost procesa odreĊuju: produktivnost, adaptivnost i korisnička

prihvatljivost procesa. Na produktivnost (efektivnost) procesa utiĉu:
neodgovarajući bezbednosni ciljevi kontrola zaštite, nerealni ciljevi
servisa zaštite, neefikasni kontrolni mehanizmi i slabo dizajniran tok
procesa. Adaptivnost zahteva da je proces sposoban da se prilagodi
promenama okruţenja, odnosno da dizajn procesa mora ugraditi zahteve
za fleksibilnost asimilacije novih funkcionalnosti i skalabilnost
(proširenje obima i nadogradnju novih kontrola zaštite). Korisniĉka
prihvatljivost podrazumeva da dizajn procesa mora zadovoljiti zahteve
krajnjih korisnika i da proces bude u skladu sa kulturom organizacije,
manje zavisan od specifiĉnih znanja i veština (manje kompleksan) i
psihološki prihvatljiv (interesantan, stimulativan i usklaĊen sa
sposobnostima korisnika).

Poboljšavanje procesa je klasiĉni cilj upravljanja kvalitetom. Najbolje se

postiţe strukturnim pristupom za identifikaciju i izvršavanje

- 293 -
modifikacije, kroz sledeće korake: razumevanje i dokumentovanje
tekućeg procesa; dekomponovanje proces u skup sadrţanih procedura i
pomoćnih mehanizama; odreĊivanje redosleda procedura prema
prioritetu potreba za poboljšanjem; identifikovanje ţeljenog stanja za
svaku proceduru; planiranje implementacije kao serije postupnih
(inkrementalnih) poboljšanja i implementacija i upravljanje zavisnostima
izmeĊu procedura.

- 294 -
5. KLJUĈNI TERMINI

Aktivnost zaštite: ĉini je skup osnovnih, generiĉkih praksi (radnji).

Efektivnost procesa: „ĉinjenje pravih stvari― odraţava u kojoj meri skup
aktivnost procesa ispunjava postavljene bezbednosne ciljeve efektivan
bezbednosni proces je onaj koji smanjuje rizik u skladu sa oĉekivanjem
(ni previše ni premalo).
Efikasnost procesa: „rentabilno izvršavanje pravih stvari―, meri
troškove proizvodnje izlaznih rezultata u odnosu na ulaz, ili brzinu
izvršavanja aktivnosti procesa, pa će visoko efikasan proces proizvesti
oĉekivani izlazni rezultat po najniţoj ceni i u najkraćem vremenu.
Ponovljivost ili vremenski ciklus procesa: mera brzine sa kojom se
izlazni rezultat moţe proizvesti poboljšanje vremenskog ciklusa
(smanjenje perioda ponavljanja) smanjuje se kašnjenje izmeĊu prijema
ulaznih i proizvodnje izlaznih rezultata.
Procedura: povezuje skup aktivnosti zaštite, odreĊujući redosled i naĉin
izvršavanja tih aktivnosti.
Proces: skup procedura (povezanih aktivnosti) koje imaju svoj poĉetak i
kraj i koje izvršavaju jedinstven zadatak (usmerene su na jedinstven cilj i
rezultat); mehanizam koji u odreĊenom vremenskom periodu
transformiše skup ulaznh podataka i informacija u skup izlaznih rezultata
(podataka i informacija).
Produktivnost procesa: mera u kojoj se oĉekivani izlaz procesa moţe
postići sa fiksnim skupom resursa i u zadatom vremenu.
Projekat: skup procesa koji imaju svoj poĉetak i kraj, obim i granice i
definisane resurse, a koji su usmereni na izvršavanje jedinstvene funkcije
(cilja, zadatka).
Stabilan proces: zreo proces koji poseduje zadovoljavajuću
produktivnost, adaptivnost i korisniĉku prihvatljivost.
Zrelost procesa: mera u kojoj je proces eksplicitno definisan, izvršen,
upravljan, merljiv, kontrolisan i efektivan.

- 295 -
6. LITERATURA

1. Glenn Fourie, The evolution of the information security mindset:

a hypothesis of Stages of individual and enterprise security
maturation, http:/www.sans.com, May 8, 2002
2. Hefner Dr. Rick and Warren Monroe, System Security
Engineering Capability Maturity Model, TRW, CA,
http://www.trw.com, 1997
3. ISF – The Standard for Good Practice for Information Security,
http://www.isf.org, V.3.0., 2003.
4. ISO/IEC 17799 - Code of Practice for Information Security
management, , http://www.iso.17799.org, 2003
5. ISO/IEC 21827, System Security Engineering Capability Maturity
Model, http://www.iso.21827.org., 2000.
6. IT Baseline Protection Manual, http://www.bsi.bund.de/gshb,
juli 2000.
7. Purser S., A practical guide to managing information security,
Artech House, Boston, London, http://www.artechhouse.com,
2005.
8. Williams Jeffrey R., Ferraiolo Karen M., P3I – Protection Profile
Process Improvement, Arca Systems, Inc.,
http://www.arcasystems.com, 2003.

- 296 -
4. PROCESNI OKVIR ZA RAZVOJ PROGRAMA ZAŠTITE

0. UVOD

Kada proučite ovo poglavlje razumećete:

- prednost procesnog pristupa razvoju programa zaštite

- primenu sistemskog inženjerstva u oblasti zaštite
- primenu modela sazrevanja procesa (SSE CMM) zaštite
- redukovani SSE CMM model za razvoj programa zaštite

Metodologija sistemskog inţenjerstva (SE), jednoznaĉno

odreĊena definisanjem minimalnog i dovoljnog skupa: principa,
koncepata (modela), metoda, alata i tehnika i procesa razvoja, u
potpunosti je primenljiva za procesni razvoj programa i sistema zaštite.

Sistemsko inţenjerstvo moţe se definisati kao selektivna aplikacija

nauĉno-inţenjerskih aktivnosti, којa transformiše neke operativne
potrebe u opisni model konfiguracije sistema, koji, u skladu sa
indikatorima merenja efektivnosti, najbolje zadovoljava te operativne
potrebe. SE tehniĉkog sistema integriše tehniĉke parametre na koje se
odnosi i obezbeĊuje optimalnu kompatibilnost svih fiziĉkih, tehniĉkih,
funkcionalnih i programskih interfejsa za ceo sistem. SE kompleksnog
sistema (kakav je sistem zaštite) integriše aktivnosti svih inţinjerskih
disciplina i drugih specijalnosti u ukupnu inţinjersku aktivnost, istiĉući
ulogu multidisciplinarnosti i liderstva u integrisanju raznorodnih
tehniĉkih i ne-tehniĉkih (upravljaĉkih i operativnih) disciplina.

Za procesni razvoj programa i sistema zaštite korisna su iskustva iz

metodologije softverskog inţenjerstva (SwE), disciplinovane primene
inţenjerskih, nauĉnih i matematiĉkih principa, koncepata, alata i tehnika,
da bi se na ekonomiĉan naĉin proizveo softverski proizvod. Obuhvata
sledeće oblasti: upravljanje projektima, industrijski inženjering,
upravljanje kvalitetom, domen aplikacija, zaštitu i bezbednost,
inženjering kompatibilnosti, kompjuterski inženjering.

Koncept sistemskog inženjerstva IKT zaštite (SSE-Security System

Engineering) definiše i uspostavlja izbalansiran skup bezbednosnih
ciljeva zaštite; transformiše bezbednosne ciljeve i potrebe u dokumenta i
uputstva za zaštitu; uspostavlja poverenje u taĉnost i efektivnost

- 297 -
implementiranih tehniĉkih kontrola zaštite (mehanizama i protokola);
procenjuje da li su prihvatljive posledice uticaja preostalog rizika na
operativni rad IKT sistema i integriše sve aspekte sistema zaštite u
koherentan, kompleksni skup kome se moţe verovati.

Primena generiĉkog modela sazrevanja kapaciteta -CMM (Capability

Maturity Model) u SSE, sa posebnim osvrtom na razvoj programa zaštite,
podrazumeva dobro i ponovljivo izvršavanje specifiĉnih aktivnosti zaštite
koje su deo odreĊenog procesa. Koliko će se dobro izvršiti i ponoviti te
aktivnost zavisi, delom ili u celini, od kapaciteta za izvršavanje i zrelosti
procesa za koje se aktivnosti izvršavaju. Model ne definiše puteve za
dostizanje postavljenih ciljeva ili izvršavanje specifiĉnih aktivnosti, vaţni
su samo ciljevi aktivnosti i postignuti rezultati. Detalji primene
metodologije SSE CMM za progresivan razvoj programa i sistema zaštite
nisu toliko bitni, koliko naĉin postizanja i merenja zrelosti procesa
zaštite. Merenje zrelosti procesa u SSE CMM kljuĉni je faktor u svim
fazama razvoja modela i primene za progresivan, projektno orijentisan
razvoj programa zaštite. Kapacitet organizacije u oblasti zaštite generalno
se odreĊuje sa tri kritiĉna resursa organizacije: specijalisti zaštite, procesi
zaštite i tehnologija za zaštitu.

- 298 -
1. OSNOVE SSE CMM METODOLOGIJE

1.1. Osnovni problemi SSE

Na osnovu iskustava iz prakse zaštite u oblasti SSE mogu se uoĉiti tri

osnovna problema:

1. Tekuća praksa zaštite nema dobro definisane procese koje

organizacija moţe direktno koristiti za poboljšavanje inţenjerskih
aktivnosti relevantnih za rešavanje problema u zaštiti. Rezultati
SSE ukazuju da se procesi zaštite ĉešće smatraju odvojenim, nego
integralnim delom ukupnog procesa razvoja IS.
2. ProizvoĊaĉi hardverskih i softverskih komponenti zaštite ne
poseduju, ili ne koriste adekvatne mehanizme za procenu svojih
SSE kapaciteta.
3. U evaluaciji projekata razvoja proizvoda/sistema zaštite najĉešće
se pogrešno prenaglašavaju konaĉni rezultati, a u stvari se ocene
odnose na procese sa kojima se postiţu ti rezultati.

Uoĉavajući ove probleme, oĉigledno, postoji potreba za razvojem SSE

modela mehanizama za procenu/evaluaciju kapaciteta za razvoj
komponenti i sistema zaštite. Osnovu ovog koncepta ĉini primena
modela za sazrevanje ili progresivni razvoj kapaciteta procesa - CMM
(Capability Maturity Model). U svakoj primeni CMM treba razmatrati
kako se ovi indikatori kapaciteta odnose na objekat za kojeg se CMM
razvija i primenjuje, [8].

- 299 -
1.2. Generiĉka struktura SSE CMM modela i metoda

Arhitektura SSE CMM generalno se razvija u dva smera (SL. 1.1):

1. Oblast primene (The Domain Side) i

2. Oblast kapaciteta (The Capability Side).

SSE CMM
model

DOMEN NIVOI ZRELOSTI

(oblast primene) KAPACITETA

OBLAST ZAJEDNIČKE
PROCESA KARAKTERISTIKE
(OP) (CF)

BAZIČNE Evaluiraju GENERIČKE

PRAKSE PRAKSE
(BP) (GP)

Sl. 1.1. Struktura SSE CMM modela i metoda

Oblast primene obuhvata tri kategorije oblasti procesa (OP):
 inženjerske ili SSE (inţenjerski – za inţenjering i analizu),
 upravljačke (projektni – za projektovanje i koordinaciju) i
 organizacione (za ljude i procese koje ti ljudi izvršavaju).
Oblast procesa (OP) je skup odnosnih kolektivno izvršavanih osnovnih
aktivnosti - BP (Basic Practices), ĉije se izvršavanje zahteva za
postizanje bezbednosnih ciljeva OP, pri ĉemu nije toliko vaţno kakve su
BP, nego da su implementirane da bi se postigla namena OP koju BP
podrţavaju. Smatra se da svaka od identifikovanih BP doprinosi
efektivnom izvršavanju OP i zbog toga se BP unutar specifiĉne OP mora
izvršiti. OP skuplja relevantne aktivnosti zaštite u celine koje se mogu
implementirati kao odvojeni proces, a u skladu sa zahtevom modela, nije
obavezno da se svaka OP definisana u modelu izvrši.Oblasti procesa iz
sve tri kategorije u suštini su sliĉne. Drugim reĉima, sve tri kategorije OP

- 300 -
u SSE CMM treba da bude integrisane i prikazane u Integralnom
katalogu oblasti procesa, jer se samo takvim pristupom obezbeĊuje
progresivno poboljšavanje ukupnih kapaciteta programa zaštite
(inţenjersko-tehnoloških, upravljaĉko-projektnih i organizaciono-
kadrovskih). SSE CMM obezbeĊuje oblasti procesa za kompletno
pokrivanje ţivotnog ciklusa sistema zaštite, odnosno, iste baziĉne
aktivnosti SSE OP primenjive su u svim fazama ţivotnog ciklusa
sistema/proizvoda zaštite.

- 301 -
Integralni katalog OP SSE CMM sadrţi sledeće kategorije OP (Tabela
1.1), [6].
SSE OP Upravljaĉke (projektne) OP Organizacione OP
OP 01 – Administriranje OP. 12: Osiguranje sistema
kontrola zaštite kvaliteta OA 17: Definisanje SSE
(specifikacija potreba procesa organizacije
zaštite)
OP 02 – Procena uticaja OP.13. Upravljanje OA 18: Poboljšanje SSE
konfiguracijom procesa organizacije
OA 19: Upravljanje
OP 03 – Procena
OP. 14: Upravljanje rizikom evaluacijom proizvoda
bezbednosnog rizika
zaštite
OP 04 – Procena pretnji OP 15. Kontrola razvoja OA 20: Upravljanje
sistema zaštite podrškom okruţenja SSE
OP 16: Plan tehniĉkih OP 21: ObezbeĊenje
OP 05 – Procena
aktivnosti razvoja sistema potrebnih znanja i
ranjivosti sistema
zaštite sposobnosti kadrova
OP 06 – Izgradnja OA 22: Upravljanje
bezbednosne garancije akvizicijom komponenti
(security assurance) sistema zaštite
OP 07 – Upravljanje
sistemom zaštite
OP 08 – Nadzor i
kontrola sistema zaštite
OP 09– ObezbeĊenje
implementacije sistema
bezbednosti i zaštite
OP 10 – Specifikacija
bezbednosnih ciljeva i
zahteva za zaštitu
OP 11 – Verifikacija i
validacija
proizvoda/sistema zaštite
T.1.1. Kljuĉne oblasti procesa u tri opšte kategorije SSE CMM

U primeru u tabeli identifikovane su 22 kljuĉne oblasti procesa. Treba

zapaziti da SSE CMM ne propisuje specifiĉne procese ili aktivnosti, nego
daje opšti model za formiranje i grupisanje procesa i aktivnosti zaštite.

Osnovna aktivnost (BP) mora se izvršiti u implementiranom procesu i

primenjuje su u celokupnom ţivotnom ciklusu sistema i uglavnom se ne
preklapa sa drugim BP. Generalno, BP predstavlja najbolju praksu

- 302 -
zaštite koju preporuĉuje meĊunarodna interesna zajednica u oblasti
zaštite. BP ne specificira neki poseban metod ili alat, već je pre
preporuĉena organizacija za izvršavanje aktivnosti u OP. Lista BP
prikazuje se u Integralnom katalogu OP na standardizovan naĉin:

Primer: Lista osnovnih aktivnosti (BP) u OP: Evaluacija informacionih sistema i

IKT proizvoda:
BP.01.01 Uspostavi kriterijum evaluacije na bazi identifikovanog problema i njegovih
definisanih ograniĉenja.
BP.01.02 Definiši generalni pristup (koncept) za analizu, na bazi uspostavljenog
kriterijuma za evaluaciju.
BP.01.03 Identifikuj alternativna rešenja za evaluaciju, pored onih datih u izjavi o
identifikovanju i definisanju problema.
BP.01.04 Analiziraj konkurentna potencijalna rešenje problema, na osnovu
uspostavljenih kriterijuma evaluacije.
BP.01.05 Izaberi rešenja koje zadovoljavaju uspostavljeni kriterijum evaluacije.
BP.01.06 Definiši naĉin, mesto i razloge odbacivanja svake razmatrane alternative.

Oblast kapaciteta (The Capability Side) koja obuhvata tri kategorije:

 generičke radnje (Generic Practices)-GPs,

 zajedničke karakteristike (Common Features)-CFs i
 nivoe zrelosti kapaciteta (Capability Levels)-CLs
Generičke radnje (GP) predstavljaju izvorne, opšte radnje koje se
izvršavaju u svim procesima (OP) u domenu, a koje odreĊuju kapacitete
organizacije za izvršavanje procesa. GP su poredane prema svojoj
zrelosti, tako da GP sa većom zrelosti ukazuje na viši nivo kapaciteta
procesa. GP moraju biti izvršene u nekoj OP, kao deo izvršavanja BP.
GP se koriste u progresivnom poboljšavanju procesa (appraisal) za
odreĊivanje kapaciteta procesa. GP se grupišu prema zajedniĉkim
karakteristikama (CF) po nivoima (zrelosti) kapaciteta (CL) od 1 do 5
(Tabela 1.2), od kojih svaki sadrţi nekoliko CF. GP su aktivnosti za
implementaciju ili institucionalizaciju, koje poboljšavaju kapacitet za
izvršavanje svakog procesa u konkretnoj kategoriji OP. Na primer:
dokumentovanje procesa, dokumentovanje pristupa za izvršavanje OP na
osnovu standarda i/ili procedura.
Nivo
kapaciteta Zrelost kapaciteta
(CL)
1. Izvršavan neformalno

- 303 -
 Planiran, kompletiran i kontrolisan
2.
(praćen)
3. Dobro definisan
4. Kvantitativno kontrolisan
5. Kontinualno poboljšavan

T. 1.2. Nivoi zrelosti kapaciteta generiĉkog SSE CMM

Zajedničke (opšte) karakteristike - (CF) su svi zajedniĉki aspekti
procesa, grupisani u logiĉke oblasti - nivoe kapaciteta. CF sadrţe jednu
ili više GP, a organizovane su 5 (6) nivoa zrelosti kapaciteta -CL
(Capability Level), s tim što se 0 nivo obiĉno izostavlja u prezentaciji
modela, jer oznaĉava da proces nije izvršen. U generiĉkom CMM zrelost
kapaciteta meri se na 5 progresivno rastućih nivoa razvoja, što je
usvojeno i u SSE CMM. U Tabeli 1.3. prikazane su CF po nivoima
zrelosti kapaciteta.
Nivo
kapacitet Zajedniĉke karakteristike (CF)
(CL)
1. 1.1. BP su izvršene
2.1. Planiranje aktivnosti (performansi)
2.2. Disciplinovanje aktivnosti
2.
2.3. Verifikacija aktivnosti
2.4. Praćenje aktivnosti
3.1. Definisanje standardnog procesa
3. 3.2. Izvršavanje definisanog procesa
3.3. Koordinacija procesa
4.1. Uspostavljanje merljivih ciljeva kvaliteta
4.
4.2. Objektivno upravljanje aktivnostima
5.1. Poboljšanje organizacionih kapaciteta
5.
5.2. Poboljšanje efektivnosti procesa

T.1.3. Zajedniĉke karakteristike (CF) po nivoima zrelosti kapaciteta

Nivoi kapaciteta (CL) sadrţe CF i predstavljaju povećane ukupne

kapacitete. Postoji više naĉina da se GP grupišu u CF i CF u CL. Nivo
kapaciteta definiše se kao jedinstveni skup aktivnosti sa zajedniĉkim
karakteristikama (CF) u svim OP koje se izvršavaju interaktivno sa
ciljem da se obezbedi glavno poboljšanje kapaciteta za izvršavanje
procesa. Na primer: 2. nivo - Planiran, kompletiran i kontrolisana

- 304 -
(praćen). Svaki nivo kapaciteta dekomponuje se u skup CF koje sadrţe
skup GP. Svaka GP je opisana detaljno posle kratkog opisa CF.

U PRILOGU II 4A opisane su sve generiĉke prakse (GP) i zajedniĉke

karakteristike (CF) SSE CMM modela V.3.0. Glavni principi
struktuiranja nivoa zrelosti kapaciteta dati su u PRILOGU II 4B.

- 305 -
1.3. Struktura Integralnog kataloga oblasti procesa SSE-CMM modela

Oblasti procesa (OP) u SSE CMM obuhvaćene u Integralnom

katalogu OP, definišu se: nazivom, ciljem i kratkim opisom, kao u
sledećem primeru, ukljuĉujući sve pripadajuće BP.

OP: Administracija kontrola zaštite

Opis: Uspostavlja odgovornosti u programu zaštite, upravlja
konfiguracijom sistema zaštite, upravlja programima podizanja svesti o
potrebi, obuci i obrazovanju i upravlja servisima i mehanizmima kontrola
zaštite. Namena ove OP je da osigura da je namenjena zaštita sistema
koja je integrisana u projekat sistema faktiĉki postignuta sa sistemom u
operativnom stanju.
Ciljevi: Kontrole zaštite su propisno primenjene i konfigurisane su?
Bazične prakse (BP)
1.1.1. Uspostavljene i prihvaćene odgovornosti za kontrole zaštite,
upoznati svi zaposleni u organizaciji?
1.1.2. Upravljana konfiguracija kontrola zaštite sistema?
1.1.3. Upravljani programi podizanja svesti o potrebi zaštite, obuke i
edukacije za sve korisnike I administratore?
1.1.4. Upravljano periodiĉno odrţavanje I administracija servisa zaštite i
kontrolnih mehanizama?

Elementarne BP definišu se sa: brojem, nazivom, opisom, tipičnim

rezultatima i napomenom (potencijalne tehnike, metodi i.t.d.), kao u
sledećem primeru:

BP.01.01 Uspostaviti kriterijum evaluacije

Opis: kriterijumi korišćeni u procesu evaluacije mogu znaĉajno varirati,
zavisno od identifikovanog problema i nivoa kompleksnosti analize.
Kriterijumi se rangiraju po redosledu znaĉaja. Za kompleksnije analize
kriterijumi se mogu podeliti po nivoima.
Tipični rezultati: identifikovani kriterijumi evaluacije, kriterijumi za
procenu kvaliteta studija i kriterijumi za odreĊivanje grešaka u podacima.
Napomena: Na nivou IS, primarni parametri su funkcionisanje sistema,
efektivnost, podrška, rizik, operativna raspoloţivost i pogodnost
odrţavanja.

- 306 -
U sledećem primeru dat je kompletan kataloški opis 1. nivoa kapaciteta.

Primer: 1. Nivo kapaciteta: Izvršen neformalno

Kratak opis:
BP OP generalno se izvršavaju. Izvršavanje ovih BP ne mora biti
rigorozno planirano i praćeno. Izvršavanje BP zavisi od individualnih
znanja, veština i napora. Proizvodi rada OP ispituju se na izvršavanje.
Pojedinci u organizaciji prepoznaju da neka akcija treba biti izvršena i
postoji opšta saglasnost da je neka akcija izvršena kada i gde se to
zahteva. Postoji proizvod rada procesa koji se moţe identifikovati.
Lista CFs:
Ovaj nivo kapaciteta sadrţi sledeće CF:

CF 1.1 – BP su izvršene
 CF 1.1 – BPs su izvršene

Kratak opis:

GPs ove CF jednostavno da se BP OP izvršavaju na neki naĉin.

MeĊutim, konzistentnost ili izvršavanje i kvalitet proizvedenog rezultata
rada procesa verovatno je da mnogo varira zbog nedostatka
implementiranih kontrola.

Lista GPs:

CF se sastoji od sledećih GPs:

GP 1.1.1 – Izvrši proces

 GP 1.1.1 – Izvršavanje procesa

Opis:

Izvrši proces koji implementira BP OP da obezbedi proizvod rada i/ili

servis za klijenta.

Primedba:

Proces moţe biti »neformalni«, a klijent(i) OP mogu biti interni i eksterni

za organizaciju.

- 307 -
1.4. Mogućnosti primene SSE CMM u oblasti zaštite

Osnovna svrha primene SSE CCM , što svaka organizacija ne

zahteva isti nivo zrelosti u svim procesima koje organizacija koristi u
oblasti IKT zaštite. Model meri zrelost procesa kojima se izvršavaju
ključne aktivnosti u oblasti zaštite.

Generiĉki CMM moţe se primenjivati u razliĉitim oblastima SSE CMM

i to za, [8]:

 merenje progresivnog sazrevanja kapaciteta programa zaštite,

 poboljšanje profila zaštite IKT sistema [9],
 merenje sazrevanja kapaciteta procesa za razvoj softverskih
proizvoda za zaštitu;
 merenje progresa sazrevanja kapaciteta procesa za razvoj kadrovskih
potencijala organizacije,
 merenje progresa sazrevanja kapaciteta procesa za obuku specijalista
za zaštitu,
 merenje progresa sazrevanja procesa za razvoj organizacione
strukture zaštite,
 definisanje i razvoj optimalnog programa zaštite,
 pojednostavljenje i ubrzavanje procesa evaluacije i sertifikacije
sistema zaštite,
 izbor kvalifikovanog tima za projektovanje, akviziciju i integraciju
sistema zaštite,
 definisanje upravljaĉkih procesa, razvoj i poboljšanje implementacije
plana zaštite i
 poboljšanje funkcionalnih procesa organizacije stalnim poboljšanjem
oblasti zaštite.

Primenom SSE CMM za definisanje i razvoj optimalnog programa

zaštite u IKT obezbeĊuje se:
 poverenje da neka organizacija realizuje planirani program zaštite
(kakav tvrdi da jeste);
 blagovremeni razvoj programa zaštite u granicama raspoloţivog
budţeta i
 metriku za odreĊivanje adekvatnosti komponente za specificirani
proces u oblasti zaštite.

- 308 -
Osnovne faze razvoja SSE CMM za definisanje, razvoj i izbor
optimalnog programa zaštite su:

1. Identifikovanje atributa „zrelosti“ procesa za razvoj programa

zaštite:

 specificiranih po modelu procesa,

 korišćenih u kontekstu naĉina izvršavanja procesa i
 iskoristivih za procenu zrelosti kapaciteta zaštite.

2. Merenje zrelosti procesa za razvoj programa zaštite:

 definisanje poĉetnih i ţeljenih nivoa potrebne zrelosti kapaciteta

procesa zaštite,
 procena rizika i evaluacija potencijalnih izvršioca za razvoj i
implementaciju programa,
 progresivno povećanje zrelosti procesa za dostizanje ţeljenog nivoa
zrelosti programa zaštite.

Za procenu kvaliteta procesa za razvoj programa zaštite, pored

implementacije standardizovanih glavnih principa zaštite (OECD, NIST,
GAISP), mogu se odrediti i drugi kriterijumi za ocenu efektivnosti
programa zaštite na bazi:
 procesnog pristupa planiranju, projektovanju i dokumentovanju
zaštite,
 izrade politika i procedura zaštite na osnovu rezultata procene rizika,
 izrade detaljnog plana kontrola zaštite (upravljaĉkih, operativnih i
tehniĉkih),
 razvoja procedura za vanredne dogaĊaje i oporavak IKT sistema i sl.

3. Realizacija programa zaštite u IKT sistemu obuhvata izvršavanje dve

glavne grupe procesa:

1. implementacije ili uspostavljanja aktivnosti (procesa) zaštite i

2. institucionalizacije, primene procesa zaštite u celoj organizaciji.

Institucionalizacija procesa je vaţan koncept poboljšanja procesa.

Podrazumeva da je proces izvršen i da postoji spremnost, angaţovanost i
konzistentnost za kontinualno izvršavanje istog. Proces se izvršava

- 309 -
postepeno do primene u celoj organizaciji, sa progresivnim sazrevanjem
procesa.

Za realizaciju programa zaštite potrebno je obezbediti opštu podršku

menadţmenta, razvojem svesti o potrebi zaštite i kapaciteta organizacije
za izvršavanja procesa zaštite, koja se ispoljava obezbeĊivanjem:

 potrebnih resursa (vreme, novac, alati),

 politika zaštite (koje usmeravaju izvršioce pri donošenju odluka),
 procedura i uputstava (baziranih na dobroj praksi zaštite),
 obuke (za sticanje neophodnih veština i znanja iz oblasti zaštite),
 neprekidnog nadzora i kontrole rada (da se osigura propisno
izvršavanje) i
 nadzora i kontrole kvaliteta servisa zaštite (da se osigura da je servis
izvršen sa zadovoljavajućim kvalitetom.

SSE CMM generalno obezbeĊuje: kontinuitet, ponovljivost, efikasnost i

bezbednosnu garanciju za razvoj proizvoda/sistema zaštite. Dakle, glavni
koncept SSE CMM za razvoj programa zaštite obuhvata sledeće
elementarne principe:

 definisane kriterijume za merenje zrelosti aktivnosti i procesa za

razvoj programa zaštite (naĉin izvršavanja, neprekidni nadzor i
kontrola, podrška i ponovljivost merenja),
 progresivno sazrevanja aktivnosti i procesa kapaciteta za razvoj
programa zaštite (mereno na 5 nivoa ne ukljuĉujući nulti nivo koji
indicira ne-izvršen program zaštite),
 definisan redosled povećavanja zrelosti aktivnosti i procesa
kapaciteta za razvoj programa zaštite (na sledećem višem nivou uvek
je veća zrelost kapaciteta),
 definisan cilj razvoja aktivnosti i procesa kapaciteta za razvoj
programa zaštite (uvek teţe najvišem 5.nivou zrelosti).
 definisan odziv sistema zaštite (brţi odziv ostvaruje se na višem
nivou zrelosti),
 definisani prioriteti i redosled izvršavanja aktivnosti i procesa,
 merenje progresa sazrevanja aktivnosti i procesa kapaciteta za razvoj
programa zaštite i
 komplementarnost sa uputstvima i standardima zaštite (ISO/IEC
17799, ISO/IEC 13325, NIST SP – uputstva, preporuke i standardi).

- 310 -
U cilju boljeg razumevanja SSE CMM modela, identifikokvanja procesa
zaštite i primene modela za kontrolisan i progresivan razvoj kapaciteta
procesa zaštite i merenje zrelosti procesa organizacija u oblasti zaštite,
razvijena je Vežba GII P4A, u kojoj se analizira proces profilisanja
referentnog sertifikacionog tela (CA). Na osnovu definisanih oblasti
procesa (OP), u veţbi Vežbi GII P4B predloţen je za diskusiju i
reinţenjering standardni profil rut sertifikacionog tela.

1.5. Koncept redukovanog SSE CMM za razvoj programa zaštite

Praksa zaštite potvrĊuje da organizacije u najvećem broju sluĉajeva

samo teţe (ţele) da ostvare najviši mogući nivo zaštite (5.). MeĊutim,
zbog finansijskih i drugih ograniĉenja, kao i objektivnog ne-
prepoznavanja toliko jake potrebe za implementaciju programa zaštite sa
maksimalnim kapacitetima, organizacije mogu same, na osnovu analize
faktora rizika, izabrati poĉetni nivo razvoja programa zaštite sa
tendencijom progresivnog povećanja kapaciteta zaštite i dostizanja
najvišeg ili ţeljenog nivoa zrelosti aktivnosti, procesa i kapaciteta za
razvoj programa zaštite. Ovakav pristup obezbeĊuje koncept
redukovanog SSE CMM koji obuhvata generiĉku procenu (merenje)
nivoa zrelosti aktivnosti i procesa kapaciteta za razvoj programa zaštite
prema generiĉkom CMM modelu, a sama organizacija odreĊuje:

 polazni nivo zrelosti aktivnosti i procesa kapaciteta za razvoj

programa zaštite,
 dinamiku sazrevanja aktivnosti i procesa kapaciteta za razvoj
programa zaštite,
 prihvatljiv nivo zrelosti aktivnosti i procesa kapaciteta za razvoj
programa zaštite (za većinu IKT sistema drţavnih organa i
organizacija dovoljan 3. nivo) i
 da samo program zaštite za kritiĉne misije organizacije uvek treba da
teţi najvišem (5.) nivou.

- 311 -
2. PROGRESIVNO SAZREVANJE KAPACITETA ZA RAZVOJ
PROGRAMA ZAŠTITE

Okvir za sazrevanje kapaciteta (Capability Maturity Framework) u

SSE CMM modelu definiše nivoe zrelosti procesa za razvoj programa
zaštite. Svaki nivo obuhvata neki skup specifiĉnih kapaciteta
upravljačkih (projektnih), organizacionih i tehničkih (inženjerskih ili
SSE) procesа, ĉija se zrelost meri i opisuju sledećim atributima, [6], [10]:

 upravljačkim kontrolama,
 definicijom procesa,
 merenjem zrelosti procesa i
 kontrolom izvršavanja procesa.

Sazrevanje i zrelost procesa definišu se minimalnim setom atributa

kapaciteta organizacije za izvršavanje, kontrolu, podršku, monitorisanje
toka izvršavanja nekog procesa i ponovljivost rezultata izvršenog
procesa.

Generički SSE CMM definiše 5 (6) nivoa sazrevanja procesa, odnosno

kapaciteta za razvoj programa zaštite. Svaki od ovih nivoa sadrţi
odreĊeni broj osnovnih aktivnosti (BP), koji podrţavaju i omogućavaju
izvršavanje OP na datom nivou. Na slici Sl. 2.1. grafiĉki je prikazan put
progresivnog narastanja i poboljšanja kapaciteta na svakom sledećem
nivou zrelosti u SSE CMM.

0. Nivo – Nije izvršen

Opis: ovaj nivo nema zajedniĉke karakteristike (CF). Baziĉne praktiĉne
aktivnosti (BP) generalno se izvršavaju, ali postoje opšte slabosti u
izvršavanju BP u OP. Gde postoje proizvodi rada to je rezultat
izvršavanja procesa koje nije lako identifikovati ili im pristupiti. U
modelu na Slici 2.1 ovaj se nivo obiĉno ne prikazuje, [9].

- 312 -
 5. ADAPTIVAN

4. VERIFIKOVAN

3. IMPLEMENTIRAN

2. KOMPLETIRAN

DOKUMENTOVAN,
1. NEKOMPLETAN

Sl. 2.1. Pregled nivoa zrelosti kapaciteta generiĉkog SSE CMM

1. Nivo – Dokumentovan, nekompletno i neformalno implementiran

Opis: Zadovoljava osnovne zahteve, normativno je usklaĊen i
standardizovan (u skladu sa ISO/IEC 17799, 13335, COBIT,...).
Kriterijumi za merenje zrelosti kapaciteta aktivnosti i procesa zaštite su:
izraĊeni dokumenti programa zaštite, formirana struktura za upravljanje
razvojem programa zaštite, definisane odgovornosti svih uĉesnika i
izabrana i primenjena metodologija za upravljanje rizikom. U
PRILOGU II 4C prikazane su komplementarnosti SSE CMM i
standarda zaštite ISO/IEC 17799 i ISO/IEC 13335

2. Nivo – Planiran, kompletiran i kontrolisana (praćen)

Opis: Preuzima kapacitet i kriterijume merenja zrelosti aktivnosti i
procesa zaštite sa 1. nivoa i obuhvata ceo IKT sistem organizacije.
Planovi zaštite izraĊeni su za IS kao osnovnu podršku misije organizacije
i kao glavnu aplikaciju organizacije (npr. poslovi raĉunovodstva).
Planovi su predstavljeni svim delovima organizacije. Kriterijumi za
merenje zrelosti aktivnosti i procesa zaštite su: dobro dokumentovan
program zaštite, struktura za upravljanje uspostavljena, definisane
odgovornosti, primenjena metodologija upravljanja rizikom i odobren
Plan zaštite.

- 313 -
3. Nivo – Dobro definisan, upravljan i implementiran
Opis: Preuzima kapacitet i kriterijume merenja zrelosti aktivnosti i
procesa zaštite sa 2. nivoa. IzraĊen je Plan implementacije politike i
procedura zaštite. Razvijene su procedure za: odobravanje (autorizacije)
rada, upravljanje kompjuterskim incidentom, izveštavanje o stanju
bezbednosti i kontroli sistema zaštite i istragu incidenta. Kriterijumi za
merenje zrelosti aktivnosti i procesa zaštite su: obuka, edukacija i razvoj
svesti o potrebi zaštite, upravlja zaštitom u toku ţivotnog ciklusa IKT
sistema, implementirane politike zaštite, regularan pregled kontrola
zaštite, dokumentovane kontrole i procedure zaštite kontrola pristupa
resursima IKT sistema, izraĊena procedura za odobravanje (autorizaciju)
rada sistema i usklaĊen program zaštite sa Standardom najbolje prakse
(ISF V.4, 2003.).

4. Nivo – Kvantitativno kontrolisan, verifikovan

Opis: Preuzima kapacitet i kriterijume merenja zrelosti aktivnosti i
procesa zaštite sa 3. nivoa, a IKT sistem vrednije prema stepenu uticaja
na misiju organizacije. Meri rentabilnost i efikasnost programa zaštite, na
osnovu rezultata procene ranjivosti sistema, kombinovanih pretnji i
njihovog uticaja na identifikovane ranjivosti. Izveštava o ranjivostima
sistema (organizacije tipa CERT2 ili CIRT3) i preventivno smanjuje rizik
(instaliranjem Intrusion Protection System-IPS). Kriterijumi za merenje
zrelosti aktivnosti i procesa zaštite su: vrednost (osetljivost) informacija,
uticaj potencijalne štete na IKT sistem i misiju organizacije, merenje
rentabilnosti zaštite i efektivnosti programa zaštite, analiza rentabilnosti
programa zaštite, sistem zaštite sa proaktivnim sistemom zaštite (IPS) i
standardni procesom detekcije napada posmatra se kao sredstvo za
ostvarivanje misije organizacije i evaluacija efikasnosti sistema zaštite.

5. Nivo – Kontinualno poboljšavan, adaptivan

Opis: Preuzima kapacitet i kriterijume merenja zrelosti aktivnosti i
procesa zaštite sa 4. nivoa i povećava kapacitet i rentabilnost programa
zaštite. Sistem zaštite reaguje brzo i automatski na promene i donosi
sledeće odluke: poboljšati program zaštite, plan i procedure; poboljšati,
dodati kontrolu zaštite; poboljšati procese misije; poboljšati procese
upravljanja rizika. Kriterijumi za merenje zrelosti aktivnosti i procesa
zaštite su: sistem zaštite je integralni deo poslova organizacije,

2
Computer Emergency Response Team
3
Computer Incident Response Team

- 314 -
upravljanje ranjivostima sistema, kontinualno re-evaluira kombinovane
pretnje, adaptivno upravlja promenama, adaptivno identifikuje
nove/bolje kontrole zaštite, identifikuje /realizuje dobiti od sistema
zaštite i podstiĉe NIR ekspertskih sistema.

U PRILOGU II 4D. detaljno su opisani nivoi zrelosti kapaciteta za

razvoj programa zaštite i kriterijumi za odreĊivanje tih nivoa, odreĊeni
primenom redukovanog SSE CMM modela.

- 315 -
3. MERENJE ZRELOSTI PROCESA ZAŠTITE

Merenje zrelosti procesa zahteva brojne aktivnosti: prikupljanje

dokaza o izvršenim praktiĉnim aktivnostima, korišćenje resursa
organizacije, analizu aktivnosti internih ugovaraĉa u odnosu na spoljne
snabdevaĉe, primenu metoda merenja, taĉnost, ponovljivost i nezavisnost
procesa, [8].

Za kvalitetno merenje progresivnog sazrevanja procesa treba definisati

skup mernih atributa, za:

 neprekidno inoviranje/optimizaciju procesa,

 kvantitativno merenje procesa i nastalog proizvoda,
 praćenje standardnih procesa organizacije,
 obezbeĊenje podrške organizacije (politike, procedure, obuka)
 planiranje i upravljanje procesima,
 izvršavanje svih kljuĉnih procesa,
 izvršavanje nekih delova procesa.

Merenje OP za razvoj programa zaštite, obezbeĊuje alat razvijen u SSE

CMM za merenje SSE i upravljaĉkih procesa sistema zaštite. Naime,
pošto je SSE CMM zasnovan na procesima, a orijentisan je na oblast
zaštite informacija, metriĉki sistem treba da ima dva aspekta, [4], [5]:

1. Specifičnu metriku procesa, orijentisanu na same procese, koja se

moţe definisati sa:
- kvantitativno/kvalitativnim dokazima o nivoima zrelosti SSE OP, ili
- binarnom indikacijom prisustva/odsustva zrelog procesa.
2. Metriku sistema zaštite, orijentisanu na rezultate izvršavanja procesa
zaštite, koja:
- obezbeĊuje atribute merenja (objektivne/subjektivne, kvalitativne
/kvantitativne) rezultata SSE procesa, koji mogu posluţiti kao dokaz
efektivnosti tog procesa.

- 316 -
Opšta procedura sistema merenja zrelosti i sazrevanja procesa
(kapaciteta) za razvoj programa zaštite obuhvata sledeće glavne
aktivnosti, [9]:

1. Na svakom nivou (1-5) modela ponderisati sve izabrane OP

teţinskim faktorima od 1-5 koji pozicioniraju datu OP na
odgovarajući nivo zrelosti (npr. sve OP =3 nalaze se na 3. nivou
zrelosti, sve OP=1, na 1. nivou zrelosti i.t.d.). Obiĉno se dijagram
profila ne opterećuje sa 0.-tim nivoom ne-implementiranih OP.
2. Na svakom nivou izraĉunati ukupan zbir teţinskih faktora svih
OP, koji pokazuje nivo zrelosti na datom nivou SSE CMM
razvoja programa zaštite.
3. Razlika izmeĊu zbira teţinskih faktora zrelosti OP na višem nivou
u odnosu na niţi nivo, pokazuje kvantitativnu meru progresivnog
razvoja „zrelosti― procesa i kapaciteta programa zaštite na višem
nivou.
4. Izradom osnovnog (referentnog) profila zrelosti procesa na
ţeljenom nivou, primenom opšte procedure merenja i profila
sazrevanja procesa, posle nekog vremena meri se tekući profil i
odreĊuju se razlike zrelosti svake OP ili zbira OP na
odgovarajućem nivou kapaciteta u referentnom i tekućem profilu,
koje indiciraju nivo progresivnog sazrevanja svakog
pojedinaĉnog/zbirnog OP.

U procesu merenja sazrevanja procesa i kapaciteta zaštite i progresa u

razvoju programa zaštite treba imati na umu da neke:

 OP nije moguće primeniti (odnosno, ciljevi mogu uticati na procenu

OP) i da je neke
 OP teţe izvršiti (odnosno, uniformni cilj je nerealan).

- 317 -
4. REZIME

SSE CMM ne pomoţe korisniku u uspostavljanju programa

zaštite, niti da razmatra sve odgovarajuće aspekte zaštite. SEE CMM
meri nivoe zrelosti procesa zaštite. Model ne propisuje specifiĉne OP ili
BP nego daje njihovu formu i kategorizaciju i meri ukupni nivo zrelosti
kapaciteta organizacije za izvršavanje procese zaštite, da bi organizacija
dostigla odgovarajući nivo zaštite IKT sistema. SEE CMM identifikuje
snagu i slabosti neke organizacije i pomaţe fokusiranje kapaciteta na
oblasti procesa koje treba poboljšati, a pre svega na one OP koje donose
najveći progres poboljšanja.

Dokumenta zaštite ((ISO/IEC 17799, ISO/IEC 13325, NIST SP, uputstva

i standardi) i SSE CMM su komplementarni. Mapiranje iz drugih
standarda zaštite u SSE CMM i obrnuto relativno je jednostavno; razlika
je u filozofiji naĉina njihovog korišćenja.

Redukovani SEE CMM je mnogo pogodniji za razvoj izvodljivog i

rentabilnog programa zaštite za ţivotni ciklus sistema zaštite.
Organizacije koriste SSE CMM model za merenje zrelosti procesa i
kapaciteta za razvoj programa zaštite, ali same odreĊuju poĉetni i ţeljeni
nivo zrelosti tih kapaciteta i dinamiku progresivnog razvoja, zavisno od
kadrovskih, organizacionih i materijalnih resursa. U većini poslovnih
sistema odgovara 3. nivo zrelosti kapaciteta za razvoj programa zaštite
(kompletiran, dobro dokumentovan i implementiran). SSE CMM
obezbeĊuje metriĉki sistem koji sadrţi dva aspekta: procesno orijentisanu
metriku i metriku orijentisanu na rezultate procesa zaštite.

- 318 -
5. KLJUĈNI TERMINI

Proces: skup aktivnosti i procedura sa definisanim resursima

(materijalnim, vremenskim, kadrovskim), koje imaju svoj poĉetak i kraj i
namenjene su za izvršavanje jedinstvenog cilja.
Oblast procesa (OP): definisani skup karakteristika koje se odnose na
procese i koji kada se zajedno izvrše mogu postići definisanu namenu
(cilj).
Kapacitet procesa: kvantitativno merljiv opseg oĉekivanih rezultata koji
se mogu postići sprovoĊenjem i izvršavanjem procesa; pomaţe da se
planiraju resursi za projektovanje i postizanje postavljenih ciljeva.
Upravljanje procesom: skup aktivnosti i infrastrukture koja se koristi za
planiranje (predviĊanje), evaluaciju i kontrolu izvršavanja procesa.
Model sazrevanja kapaciteta (CMM - Capability Maturity Model):
opisuje faze kroz koje se procesi progresivno razvijaju, definisanjem,
implementacijom i poboljšavanjem.
Nivo kapaciteta: skup praktiĉnih aktivnosti implementacije i
institucionalizacije procesa koji rade zajedno da obezbede glavno
poboljšanje kapaciteta za izvršavanje procesa.

- 319 -
6. LITERATURA

1. Bate Roger and all, A Systems Engineering Capability Maturity

Model V.1.1, Software Engineering Institute, US DoD, 1995
2. Ferraiolo Karen & Sachs Joel E., Distinguishing Security
Engineering Process Areas by Maturity Levels, USA Columbia,
1996 ferraiolo@md.arca.com, sachs@interramp.com.
3. Ferraiolo Karen M., Considerations for Re-architecting the SEI
CMM and Building Engineering CMMs, Arca Systems, Inc.,
ferraiolo@arca.va.com, 1995.
4. Hefner Dr. Rick and Warren Monroe, System Security
Engineering Capability Maturity Model, TRW, CA,
rick.hefner@trw.com, 1997.
5. Hefner Rick, Ph.D, Lessons Learned with the Systems Security
Engineering Capability Maturity Model, rick.hefner@trw.com,
2000.
6. Hopkinson John P., System security engineering capability
maturity model - Organization profiles, EWA-Canada,
John.Hopkinson@sympatico.ca, 2003.
7. Hopkinson John P., The Relationship Between The SSE CMM
and IT Security Guidance, EWA-Canada,
John.Hopkinson@sympatico.ca, 1999.
8. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
9. Petrović R.S., Ĉekerevac Z., Grubor G., Security System
Engineering Capability Maturity Model in The ICT Security, 10.
meĊunarodna nauĉna konferencija ―Rešavanje kriznih situacija u
specifiĉnim prostorima‖, Fakultet specijalnog inţenjerstva, ŢU,
Ţilina, Slovaĉka, 2005.
10. Williams Jeffrey R., Ferraiolo Karen M., P3I – Protection Profile
Process Improvement, Arca Systems, Inc., william@arca.com,
ferraiolo@arca.com, 2004.

- 320 -
5. RAZVOJ STRATEŠKOG PLANA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja:

- razumećete proces strateškog planiranja

- razumećete prednosti razvoja strategije zaštite
- razumećete proces razvoja strateškog plana zaštite
- moći ćete samostalno izraditi strateški plan zaštite

Donošenje odluke o izboru strategijskog pristupa za razvoj

programa zaštite nije jednostavna kako se ĉini, iz više razloga. Zaštita
informacija ĉesto se smatra nuţnim zlom u većini organizacija, pre nego
faktorom rasta ukupnog poslovanja. U organizacijama u kojima tekući
sistem zaštite ne radi na zadovoljavajući naĉin, postoji verovatnoća da se
zaštita potpuno zaobiĊe i nanese nepredvidljiva šteta.

Tradicionalni pristup odozgo-na dole reaktivnom sistemu zaštite poĉinje

sa definisanjem plana i politike zaštite. Razvoj i usaglašavanje plana i
politike zaštite je teţak i vremenski zahtevan zadatak. U nekim
organizacijama ovo se smatra intelektualnom veţbom bez velike
praktiĉne vrednosti.

Za sve organizacije bitno je da je program zaštite izvodljiv, a sistem

zaštite praktiĉan, da brzo i efektivno reaguje i efikasno odgovara na sve
bezbednosne zahteve. Kratkoroĉna rešenja sistema zaštite ne obezbeĊuju
dugoroĉnu stabilnost procesa (i servisa) zaštite. Dugoroĉnu stabilnost
procesa (i servisa) sistema zaštite moţe obezbediti samo strateški pristup,
koji po pravilu angaţuje sve resurse organizacije ukljuĉujući maksimalnu
podršku menadţerske strukture. S druge strane, strateške inicijative daju
slabe rezultate u kratkoroĉnim periodima.

U kojoj meri su ovi razlozi realni u nekoj organizaciji, najviše zavisi od

nivoa zrelosti procesa organizacije. Podrazumeva se da su zrelije
organizacije već dostigle odreĊene nivoe stabilnosti i zrelosti procesa, što
im omogućava da veću paţnju usmere na strateški razvoj zaštite
informacija

- 321 -
1. RAZVOJ STRATEGIJE ZAŠTITE

Organizacije sa manje zrelim i stabilnim procesima postavljaju

kratkoroĉne bezbednosne ciljeve i zahtevaju više kratkoroĉnih (ad hock)
rešenja. Na slici Sl. 1.1. prikazani su procesi dugoroĉnog (strateškog) i
kratkoroĉnog razvoja zaštite informacija u funkciji zrelosti procesa
organizacije, [9].

Strateške
inicijative
Očekivani put sazrevanja:
što je organizacija zrelija
Postiţu dugoročnu stabilmnost

sposobnija je da se usmeri
na strateške inicijative

Odgovaraju na prioritete i stiču kredibilitet Taktičke

inicijative

Sl. 1.1. Put sazrevanja procesa organizacije

Dijagram na slici 1.1. zasniva se na primeru iz klasiĉne ekonomije, koji

opisuje kako se sa ograniĉenim skupom resursa mogu postići dva
razliĉita tipa rezultata. U konkretnom sluĉaju skup resursa ĉine zaposleni
organizacije, koji su presudni za sazrevanje procesa organizacije, a
mogući izlazni rezultati su strateške ili taktiĉke inicijative u oblasti
zaštite IKT sistema. Forma krive puta sazrevanja procesa organizacije
zavisi od mere sliĉnosti dva moguća izlazna rezultata. Što su izlazni
rezultati sliĉniji kriva je sve bliţa pravoj liniji, a potpuno je konveksna
kada su izlazni rezultati razliĉiti. Konveksna kriva puta sazrevanja
procesa organizacije na Sl. 1.1. implicira da strateški pristup daje sasvim
razliĉite rezultate od kratkoroĉnih aktivnosti.

Uspešan menadţer zaštite mora imati u vidu ove ĉinjenice i biti sposoban
da utiĉe na strateški razvoj IKT i sistema zaštite u organizaciji, ali samo
snagom ugleda i poverenja kojeg uţiva u organizaciji. Zato je vaţnije
formirati i podizati svest o potrebi zaštite, ubeĊivati snagom argumenata,
a ne primoravati korisnike administrativnim merama da sprovode politike
zaštite. Kako se poverenje stiĉe vrlo sporo, a gubi vrlo brzo, veoma je

- 322 -
vaţno koliko brzo menadţeri zaštite ovladaju i kontrolišu procese zaštite.
Svaki menadţer zaštite koji preuzima odgovornost za zaštitu IKT sistema
u organizaciji, treba da razmotri dijagram na slici 1.1. Ako preliminarne
informacije i kultura organizacije pokaţu da su procesi zaštite nedovoljno
stabilni i zreli, treba preduzeti više kratkoroĉnih inicijativa za zaštitu i –
obrnuto.

U svakom pristupu zaštiti (strateškom ili taktiĉkom) uvek treba imati u

vidu da je poverenje u IKT sistem i organizaciju u celini uvek poslednja
barijera koju mora savladati svaki program i sistem zaštite.

- 323 -
1.1. Ciklus strateškog planiranja zaštite

Proces IKT zaštite je kontinualni i cikliĉno promenljivi (kruţni

proces sa povratnom spregom), zbog neprekidne promene bezbednosnog
okruţenja (pretnji, tehnologija, poslovnog okruţenja). Na isti naĉin
strateško planiranje mora biti cikliĉan i neprekidan proces. Na slici Sl.
1.2. prikazan je funkcionalni model ciklusa strateškog razvoja plana
zaštite, [9].

Izrada
Definisanje strateškog
strategije plana

Strateško
planiranje

Realizacija
Monitoring plana

Sl. 1.2. Ciklus strateškog planiranja zaštite

Na Sl. 1.2. nisu uzete u obzir procedure i aktivnosti u pojedinim fazama

ciklusa, nego samo opisane kljuĉne funkcije ţivotnog ciklusa strateških
inicijativa. Ovo je posebno vaţno kada se izraĊuje strateški plan zaštite,
pošto nivo zrelosti organizacije odreĊuje nivo inţenjerskih, upravljaĉkih i
organizacionih napora posvećenih strateškom razvoju zaštite. Ovaj model
je samo aproksimacija stvarnosti na odreĊenom nivou i ne treba ga
shvatiti bukvalno. Na primer, u stvarnosti nikada ne ĉekamo kraj ciklusa
da bi uveli i implementirali nove ideje i strateške inicijative, nego to
ĉinimo u toku poslednje faze.

Ciklus strateškog planiranja zaštite sadrţi 4 faze:

1. Definisanje strategije (dugoroĉnih ciljeva) zaštite;
2. Izrada strateškog plana zaštite (akcioni plan sa inicijativama i
prioritetima kratkoroĉnih projekata zaštite);
3. Realizacija strateškog plana zaštite (izvršavanje projekata zaštite
prema prioritetima i dinamici iz akcionog plana) i
4. Monitoring i kontrola izvršavanja projekata zaštite u cilju daljeg
poboljšavanja sistema zaštite.

- 324 -
Definisanje strategije zaštite je poĉetna pozicija za novi ciklus strateškog
planiranja. Svaki proces za upravljanje promenama u bilo kojem
uspostavljenom sistemu poĉinje sa definisanjem tekućeg i ţeljenog
stanja, a zatim se definiše naĉin tranzicije iz jednog u drugo bezbednosno
stanje sistema. Ovakav pristup je jedan od najefikasnijih naĉina za
definisanje strategije zaštite IKT sistema.

Strategija je jedan od kljuĉnih elemenata za obezbeĊenje dugoroĉnog

uspeha metodologije sistema IKT zaštite, pošto sadrţi konsolidovanu
viziju sadašnjeg i budućeg, ţeljenog bezbednosnog stanja sistema zaštite.
Za definisanje strategije zaštite zahteva se potpuno razumevanje sledećih
pitanja:

- jake i slabe taĉke postojećeg sistema zaštite (bezbednosno stanje-

BS1 u To),
- tekući i oĉekivani trendovi u oblasti pretnji i ranjivosti sistema,
- moguća evaluacija bezbednosnog softvera,
- poslovna i IKT strategija organizacije i
- nivo angaţovanja na smanjenju rizika i raspoloţivost budţeta.

Prva i druga taĉka reflektuje nivo razumevanja postojećeg bezbednosnog

stanja, a preostale taĉke se uzimaju u obzir kada se definiše ţeljeno
bezbednosno stanje. U procesu razvoja strategije zaštite treba uzeti u
obzir sledeća pitanja:

- strategija treba da pokrije period od 3-5 godina, dovoljno dug za

implementaciju znaĉajnih promena, a dovoljno kratak za
predviĊanje tehnološkog razvoja,
- strategiju zaštite treba da prati i komponenta strategije razvoja
personalne zaštite, da se obezbede prihvatljivost i kompetentan
tim za implementaciju vizije,
- ukoliko menadţer zaštite preuzima ulogu u vreme definisanja
strategije, dobro je smatrati period uvoĊenja u posao, prvom
fazom izrade strategije i
- koristiti fazni pristup i definisati kontrolne taĉke tako da se moţe
kontrolisati progres.

- 325 -
Dokument strategije obezbeĊuje mapiranje akcija u oblasti zaštite na
visokom nivou za nekoliko sledećih godina. Struktura dokumenta
strategije zaštite sadrţi (Sl. 1.3):

- presek stanja zaštite,

- viziju za dostizanje ţeljenog bezbednosnog stanja,
- inicijative za dostizanje tog stanja,
- sistem indikatora za praćenje progresa i
- akcioni plan projekata za izvršavanje strateškog cilja.

STRATEGIJA
(vizija, inicijative, indikatori
progresa, akcioni plan)
IKT IKT
sistem sistem

Presk stanja

To, BS1 T1, BS2

Sl. 1.3. Strategija zaštite

Analiza preseka bezbednosnog stanja IKT sistema-BS1 u vremenu-To

podrazumeva analizu rizika i merenje efektivnosti i efikasnosti postojećih
kontrola zaštite. Vizija obuhvata dugoroĉne (strateške) bezbednosne
ciljeve stanja bezbednosti IKT sistema-BS2 u taĉki T2. Dokument
Strategija zaštite obezbeĊuje osnovni okvir za pomeranje nivoa
bezbednosti IKT sistema sa BS1 u To na BS2 u T1. Nije dobro
ukljuĉivati bilo koju vrstu detaljnog planiranja u stratešku viziju i treba
predvideti neophodno aţuriranje izmena plana. Da strategija ne bi ostala
licenca za trošenje novca, organizacije dopunjuju strategiju internim
predlozima – inicijativama koje sadrţe skup projektovanih, glavnih
aktivnosti i akcionim planom za izvršavanje tih inicijativa. Ovakva
dekompozicija strategije omogućava da se glavne aktivnosti (inicijative)
planiraju i izvršavaju manje više nezavisno. Inicijativa predstavlja skup
akcija po prioritetima. Jedan strateški plan moţe obuhvatiti više
inicijativa. Akcioni plan je dinamiĉki plan za izvršavanje projekata u
okviru inicijativa po prioritetima, a dobro je da sadrţi potrebne resurse
(ljudske, finansijske, vremenske). Dokument strategije zaštite treba da
sadrţi indikatore progresa razvoja strategije (benčmarking sistem) za
praćenje stanja progresa u razvoju strategije zaštite. Primer atributa

- 326 -
standardnog (EU) benĉmarking sistema primenjen na praćenje razvoja
strategije uvoĊenja sistema e-Uprave dat je u PRILOGU II 5A.

Da bi se strategija zaštite razvila i implementirala, na taktiĉkom nivou u

fazama razvoja akcionog plana i implementacije konkretnih projekata,
potrebno je razviti metodologiju, obezbediti tehnologiju i definisati
odgovornosti za implementaciju i operativnu praksu sistema zaštite. Ove
aktivnosti nisu predmet razmatranja samog dokumenta Strategije zaštite.

Izrada strateškog plana zaštite obezbeĊuje prevoĊenje strategije zaštite

u seriju inicijativa, sa vremenskim i dinamiĉkim akcionim planom. Pošto
strategija zaštite govori šta treba postići, odnosno koje dugoroĉne
bezbednosne ciljeve, kao i o prioritetima izvršavanja inicijativa na
visokom nivou apstrakcije, strateški plan odreĊuje kako ove inicijative
treba izvršiti kroz detaljan akcioni plan sa vremenskim okvirima i
finansijskim troškovima. Opšti model planiranja prikazan je na Sl. 1.4.

Strateški ciljevi

Strateški planovi

Operativni planovi Za aktivnosti

Za aktivnosti koje koje se
se ne ponavljaju ponavljaju

Kratkoročni planovi Dugoročni planovi

Standardne procedure i
Programi
metode

Budţet

Projekti Pravila

Sl. 1.4. Opšti model planiranja u organizaciji

- 327 -
U izradi strateškog plana zaštite posebno kritiĉno je planiranje vremena
izvršavanja strateških inicijativa. Zato je korisno primenjivati sledeće
metode:

- U svakom trenutku strateški plan treba da sadrţi kratkoroĉne

akcione komponente (projekte) sa vremenskim ograniĉenjem
izvršavanja do 6 meseci, sa visokim nivoom detalja i dugoroĉne
komponente u znaĉenju glavnih zadataka (inicijativa) sa manje
detalja;
- Nivo vanrednih dogaĊaja u glavnim zadacima, tokom vremena
planirati da raste;
- Inicijalni strateški plan treba izraditi kroz seriju najmanje 3
sastanka (svake sedmice po jedan).

U prvom koraku svim organizacionim liderima i IKT odeljenju zaštite

(interni rukovodioci, administrator i specijalisti zaštite) dostaviti kopije
Strategije zaštite, sa zahtevima da odrede listu prioritetnih projekata u
svakoj inicijativi i predloţe zadatke (aktivnosti) svakog projekta, bez
ikakve meĊusobne razmene informacija. Dobiće se razliĉiti rezultati. Na
1. sastanku diskutovati o ovim rezultatima i definisati opštu usaglašenu
strukturu plana. U drugom koraku ĉlanovi istog tima procenjuju zadatke
procesa svakog projekta, opet bez meĊusobne razmene informacija. Na
sledećem 2. sastanku uporeĊuju se ove procene i izraĊuje nacrt plana. Na
3. sastanku tim izraĊuje plan kratkoroĉnih projekata i zadataka
(aktivnosti).

Ova tehnika izrade strateškog plana zaštite dobro funkcioniše, ako je tim
disciplinovan i svaki pojedinac zaista radi samostalno. UporeĊivanje i
razmena mišljenja na sastancima ima najveću vrednost, jer uĉesnici
iznose svoje pretpostavke, argumente i metode. Proces razvoja strateškog
plana zaštite opisan je u poglavlju 1.2.

Realizaciju strateškog plana zaštite kroz ceo period strateškog planiranja

obeleţava konkurencija izmeĊu strateških projekata (inicijativa) i
taktiĉkih zadataka. Zato je potrebno razviti mehanizam za odreĎivanje
prioriteta, na primer gde usmeriti resurse na strateške inicijative ili
taktiĉke zadatke. Najbolji mehanizam za ovo je svakako brza analiza
rizika, koja umesto analize pretnji/ranjivosti/uticaja, uporeĊuje u kojoj
meri kašnjenje strateških inicijativa i taktiĉkih zadataka utiĉe na rizik.
Kada je reĉ o konkurenciji resursa, to se odnosi uglavnom na resurse za

- 328 -
projekte zaštite. Jedna od prednosti dekompozicije strateškog plana u
seriju projekata (u akcionom planu) je mogućnost delegiranja aktivnosti
za praćenje progresa (benčmarking sistem).

Gde god je moguće treba primenjivati postojeće standarde za upravljanje

informatiĉkim projektima, benčmarking i izveštavanje o progresu razvoja
strateškog plana. Ako standardi ne postoje (nisu usvojeni u organizaciji),
treba razviti interni standard za upravljanje strateškim projektima i
praćenje progresa strateških projekata (interni benčmarking sistem).

Monitorisanje efektivnosti strategije zaštite ukljuĉuje mnogo više

aktivnosti datih u akcionom planu, od prostog praćenja progresa
projekata. Praćenje procesa daje povratne informacije o tome kako teĉe
implementacija procesa, ali ne daje informacije koliko su nove procedure
i mehanizmi zaštite efektivni kada su već implementirani. Monitoring
efektivnosti primenjene strategije zaštite ukljuĉuje i monitoring brojnih
razliĉitih aspekata, od kojih svaki daje vaţne informacije o tome koliko
dobro strategija zaštite odgovara zahtevima organizacije. Korisne oblasti
za monitorisanje su:

- efektivnost i efikasnost procedura i mehanizama zaštite,

- prihvatljivost u korisniĉkoj zajednici,
- usklaĊenost sa strategijom poslovanja organizacije i
- usklaĊenost sa promenama okruţenja.

Za proces monitoringa sugeriše se odreĊivanje kontrolnih taĉaka u

strateškom planu. Kontrolna taĉka treba da obuhvati sastanak sa
menadţerom na kojeg utiĉe upravo završen projekat i objavljivanje plana
rada ili razgovor sa korisnicima da bi se utvrdilo kako su promene
prihvaćene.

Povratne informacije o efektivnosti mehanizama zaštite treba traţiti od

tehniĉkog osoblja u IKT sistemu. Monitorisanje korisniĉke prihvatljivosti
je trajnija aktivnost i zahteva mnogo kontakata u organizaciji. Te
informacije treba da prikupljaju svi ĉlanovi odeljenja za zaštitu, na
organizovan i sistematiĉan naĉin. Vrlo korisne su prezentacije programa
za podizanje svesti o potrebi zaštite, na kojima korisnici iznose realna
zapaţanja o prihvatljivosti novih mehanizama i protokola zaštite.

- 329 -
Monitorisanje procesa poslovne strategije treba vršiti na nivou
organizacije kroz fiksni plan aktivnosti posvećenih tom pitanju. Sve
promene poslovne strategije koje mogu uticati na strategiju zaštite
informacija treba saopštiti na tim sastancima.

Od promena okruţenja treba pratiti:

- bezbednosne alarme i informacije o ranjivostima sistema,

- trendove tehnološkog razvoja,
- studije i struĉne izveštaje o zaštiti.

Kljuĉni izlazi strateškog pristupa zaštiti informacija ĉine sledeća

dokumenta:

- Strategija zaštite informacija, koja pokriva period od 3-5 godina;

- Politika zaštite i Standardi zaštite koji je podrţavaju;
- Arhitektura sistema IKT zaštite;
- Materijal za podizanje svesti o potrebi zaštite korisnika i
menadţera.

- 330 -
1.2. Proces razvoja strateškog plana zaštite

Namena procesa strateškog planiranja je da se omogući dostizanje

sledećih ciljeva:

- postići rezultate definisane sa inicijativama u skladu sa usvojenim

vremenskim planom i budţetom,
- izvršiti reinţenjering prioriteta kratkoroĉnih ciljeva bez gubljenja
već uloţenog rada,
- odrţavati progres u razvoju vizije i pratiti probleme tehnikom
praćenja sistema indikatora progresa (benčmarkinga),
- reagovati na promene okruţenja, adekvatnim modifikovanjem
plana (promenom obima, budţeta ili trajanja projekta).

Poslednja taĉka ukazuje da je plan projekta instrument kojeg treba

koristiti kao pomoć za donošenje odluke. Kako organizacije ne ostaju
statiĉne, poĉetne planske pretpostavke koje se vremenom ne menjaju
treba da budu pre izuzetak nego pravilo. U stvari, plan koji se ne menja
vremenom, ĉesto je znak da projekat nije praćen korektno.

Izrada i korišćenje plana projekta nije predmet razmatranja, ali treba

navesti kljuĉne principe koji pomaţu da se obezbedi uspeh strategije:
- menadţer projekta treba da ima ideju koliki procenat napora tim
za zaštitu treba da posveti dnevnim aktivnostima (administraciji
zaštite i radu na projektu),
- treba iskoristiti sinergiju gde god je moguće, odnosno
poznavanje i razumevanje poslovne i IKT strategije kada se piše
strategija zaštite,
- treba koristiti brzu analizu rizika (BAR) za odreĊivanje
prioriteta izvršavanja projekata, zbog efikasnijeg korišćenja
ograniĉenih resursa [9],
- koristiti fazni pristup za veće projekte, deliti zadatke u
upravljive celine i obezbediti kontrolne taĉke za verifikaciju
progresa.

- 331 -
Proces izrade strateškog plana zaštite sadrţi sledeće faze:

1. Analiza postojećeg stanja sistema zaštite.

2. Identifikacija zahteva poslovne strategije.
3. Identifikacija zakonskih i regulatornih zahteva.
4. Identifikacija zahteva okruţenja (tehnologija, pretnje,...).
5. Definisanje ţeljenog stanja sistema zaštite (vizija
bezbednosnih ciljeva).
6. Definisanje strateških inicijativa i odreĊivanje prioriteta
izvršavanja projekata akcionog plana.
7. Distribucija nacrta strategije.
8. Usaglašavanje i objavljivanje konaĉne verzije strategije
zaštite.

Primer akcionog plana za izradu strategije zaštite prikazan na

gantogramu na Sl. 1.2. ukazuje na mogućnost paralelnog izvršavanja
odreĊenih aktivnosti.

Sl. 1.2. Akcioni plan izrade strategije zaštite

- 332 -
1. Faza: Glavni problemi u ovoj fazi aktivnosti su:

 dokumentacija postojeće strategije ne postoji,

 poslovna strategija u procesu modifikacije,
 poslovna strategija nedostupna.

2. Faza: Treba izabrati strateške inicijative koje mogu imati najveći

uticaj na proces zaštite podataka i informacija.

3. Faza: Primeri zakona koji mogu imati znaĉajan uticaj na sistem zaštite
podataka i informacija:
 Zakon o zaštiti podataka i informacija;
 Zakon o zaštiti privatnosti;
 Zakon koji se odnosi ne bezbednost poslovanja (dotiĉne
organizacije) i
 Zakon koji reguliše (ograniĉava) upotrebu kriptoloških mehanizama
zaštite.

4. Faza: Primer tipova promena okruţenja koji mogu imati dugoroĉno

gledano najveći uticaj na sistem zaštite:
 promene u tehnologiji zaštite,
 politiĉki dogaĊaji,
 nove pretnje i.t.d.

5. Faza: Ako se bezbednosni ciljevi dobro definišu, postoje dobri uslovi

da će se strateški plan ostvariti.

6. Faza: Definisanjem prioriteta izvršavanja inicijativa postiţe se

najveća sinergija akcija.

7. Faza: Distribucija nacrta strategije; strategija treba da ima sledeću

strukturu: uvod, izjava o misiji zaštite (najvećeg organa), glavni
bezbednosni ciljevi koje strategija treba dostići, izbor i opis svakog puta
u opštim crtama, opis inicijativa u svakom putu, zakljuĉak (rezime).

8. Faza: Nakon primedbi na nacrt strategije, ista se usvaja od strane

najvišeg organa uprave u organizaciji.

- 333 -
Dobra strategija zaštite savremenih poslovnih IKT sistema, zahteva
razmatranje zakona i zakonskih regulativa, relevantnih meĊunarodnih
standarda i pravila nastalih u raznim oblastima, a koje imaju implikacije
na opštu bezbednost i zaštitu IKT sistema, kao što su:

1. Standard ISO 17799, [5];

2. Standard ISO 15408, jedinstveni kriterijumi (Common Criteria
for Information Technology Security Evaluation-CCITSE), [2];
3. Standard ISO/IEC 21827, (SSE CMM) model sazrevanja
kapaciteta procesa zaštite i metod poboljšavanja procesa zaštite,
[6];
4. GAISP (Generally Accepted Information Security Principles),
opšte prihvaćeni principi zaštite, [7];
5. Nacionalni zakon, program i politika zaštite IKT sistema, [10, 11,
12];
6. Pravilnik za skladištenje i zaštitu podataka u organizacijama i.t.d.

U razvoju strategije zaštite ispravno je smatrati svako ulaganje u sistem

zaštite povratnom investicijom, ili taksom koja se plaća da bi se zaštitili
najvredniji objekti organizacije – informacije i podaci. Koliko veliku
taksu je potrebno platiti, zavisi od veliĉine rizika sa kojim se organizacija
suoĉava i koliko ţeli rizikovati.

- 334 -
2. REZIME

Dugoroĉnu stabilnost procesa i servisa zaštite moţe obezbediti

samo strateški pristup i dugoroĉno planiranje, koji po pravilu angaţuje
sve resurse organizacije i obezbeĊuje maksimalnu podršku menadţerske
strukture, ali daju slabe kratkoroĉne rezultate. Kratkoroĉna rešenja
sistema zaštite obezbeĊuju privremenu stabilnost procesa i servisa zaštite
i karakteristiĉna su za manje zrele procese i kapacitete zaštite.

Proces razvoja i izrade strateškog plana zaštite sadrţi sledeće faze:

analiza postojećeg stanja sistema zaštite; identifikacija zahteva poslovne
strategije; identifikacija zakonskih i regulatornih zahteva; identifikacija
zahteva okruţenja (tehnologija, pretnje,...); definisanje ţeljenog stanja
sistema zaštite (bezbednosnih ciljeva); definisanje strategijskih inicijativa
i odreĊivanje prioriteta izvršavanja akcionog plana; distribucija nacrta
strategije, usaglašavanje i objavljivanje konaĉne verzije strategije zaštite.

Dobra strategija zahteva razmatranje zakona i zakonskih regulativa,

relevantnih meĊunarodnih standarda i uputstava zaštite.

- 335 -
3. KLJUĈNI TERMINI

Strategija zaštite: dokument zaštite koji obuhvata presek stanja zaštite,

viziju za dostizanje ţeljenog (ciljnog) dugoroĉnog bezbednosnog stanja,
inicijative za dostizanje tog stanja, sistem indikatora za praćenje
progresa i akcioni plan projekata za izvršavanje strateškog cilja; govori
šta, odnosno, koje dugoroĉne bezbednosne ciljeve treba postići,
Plan strategije zaštite: obuhvata nivo zrelosti inţenjerskih, upravljaĉkih
i organizacionih napora organizacije na strateškom razvoju zaštite;
govori o prioritetima izvršavanja inicijativa na visokom nivou
apstrakcije; odreĊuje kako strateške inicijative treba izvršiti kroz detaljan
akcioni plan sa vremenskim okvirima, ljudskim i finansijskim resursima.

- 336 -
4. LITERATURA

1. Grance T., Hash J., Stevens M., Security Considerations in the

Information System Development Life Cycle, NIST SP 64 Rev 1.,
http://csrc.nist.gov/publications, 2004.
2. ISO/IEC 15408, Common Criteria for IT Evaluation User Guide,
http://csrc.nist.gov/cc/info/infolist.htm. 7
3. ISO/IEC 15443, Information Technology-Security Techniques,
http://www.iso.15443.org, 2000.
4. ISO/IEC 15504 (CMM), http://www.iso.15504.org, 2000.
5. ISO/IEC 17799:2000, Information Technology – Code of practice
for information security management, http://www.iso.17799.org,
2003.
6. ISO/IEC 21827 (SSE CMM), System Security Engineering
Capability Maturity Model, http://www.iso.21827.org., 2000.
7. NIST SP 800-14, Generally Accepted Principles and Practices
for Security, http://csrc.nist.gov/publications/nistpubs/800-
14/sp800-14.pdf, 1999.
8. NIST SP 800-18, Guide for developing Security Plans for IT
Systems, http://csrc.nist.gov/publications, 1998.
9. Purser S., A practical guide to managing information security,
Artech House, Boston, London, www.artechhouse.com, 2005.
10. Republika Srbija, Predlog kriviĉnog zakona, Glava 27. „Krivična
dela protiv bezbednosti računarskih podataka―, ĉlan 298-304,
2004.
11. Republika Srbija, Zakon o borbi protiv visoko tehnološkog
(kompjuterskog) kriminala, usvojen u juli 2005.
12. Republika Srbija, Zakon o elektronskom potpisu, 2004.

- 337 -
6. STRUKTURA PROGRAMA I PLANA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja naučićete:

- generičku strukturu dokumenta Program zaštite

- obim i strukturu Politika zaštite (organizacije, IS, ...)
- obim i strukturu Procedura zaštite
- obim i strukturu Plana zaštite

Program zaštite organizacije obuhvata sve što neka organizacija

ĉini da proizvede, primeni, podrţi i unapredi bezbednost IKT sistema. Da
bi se razvio i uspostavio program zaštite, treba ga bazirati na odreĊenoj
metodološkoj osnovi. Ta osnova je obiĉno u formi dokumentacije zaštite:
zakoni, standardi, uputstva, tehniĉka dokumentacija, politike, procedure,
plan zaštite i druge informacije. Uspeh nekog programa zaštite zavisi od
tri kljuĉna faktora: kvaliteta osnovne dokumentacije zaštite, pravilne
procene rizika i korisniĉke prihvatljivosti – prihvatanja programa od
strane zaposlenih u organizaciji.

Program zaštite IKT sistema organizacije ĉesto se naziva i programska

politika ili politika zaštite na najvišem nivou organizacije, uspostavlja
smernice za zaštitu, obezbeĊuje resurse za implementaciju, a obuhvate
najmanje sledeće strukturne komponente: namenu, obim, odgovornosti i
usaglašenost. Program zaštita treba da sadrţi izjavu kojom se obavezuju
odgovorna lica na izradu svih internih dokumenata zaštite. Program
zaštite treba da sadrţi najmanje sledeći set dokumenata zaštite:, Politike
zaštite, Procedure zaštite, Plan zaštite i Uputstva za zaštitu.

- 338 -
1. STRUKTURA PROGRAMA ZAŠTITE

Dokument Program zaštite IKT sistema organizacije (ili

programska politika ili politika zaštite na najvišem nivou organizacije),
relativno je kratka direktiva, koja uspostavlja smernice za zaštitu i
obezbeĊuje resurse za implementaciju. Dokument Programa zaštite
treba da obuhvati najmanje sledeće komponente, [3], [10], [12], [13],
[16]:

Namenu: izjavu koja opisuje zašto se program uspostavlja, ukljuĉujući

definisanje strateškog bezbednosnog cilja programa zaštite. Bezbednosni
zahtevi, kao što su zaštita integriteta, poverljivosti i raspoloţivosti
informacija, osnova su za definisanje bezbednosnih ciljeva.
Obim: jasno odreĊeni objekti zaštite (informacije, hardver, softver, ljudi),
koje program zaštite obuhvata. U većini sluĉajeva program zaštite
obuhvata ceo IKT sistem i njegove fiziĉke, logiĉke i korisniĉke objekte u
organizaciji, ali se moţe odnositi i na aplikaciju ili deo sistema.
Odgovornosti: uobiĉajeno je da organizacija odredi tim za upravljanje
programom zaštite. OdreĊuju se i pripisuju odgovornosti u oblasti zaštite
organizacionim jedinicama i zaposlenim u celoj organizaciji, ukljuĉujući
rukovodioce organizacionih jedinica, vlasnike aplikacija, korisnike
programa i druge zaposlene.
Usaglašenost: program zaštite tipiĉno treba da obuhvati dve vrste
usaglašenosti:

1. opštu usaglašenost, koja obezbeĊuje ispunjavanje zahteva za

uspostavljanje ciljeva programa zaštite. Kontrolori zaštite
(auditors) obavezno kontrolišu usaglašenost programske politike
zaštite sa normativima i standardima u regularnom procesu
kontrole (auditing) sistema zaštite.
2. specifičnu usaglašenost prakse zaštite sa programskom politikom
zaštite i obaveznu kontrolu ove usaglašenosti, koja podrazumeva
korišćenje specifiĉnih sankcija ili disciplinskih mera za povrede
usaglašenosti prakse i Programa zaštite.

Pošto je programska politika zaštite dokument na najvišem nivou, za

svaku neusklaĊenost prakse i programa zaštite treba planirati neku vrstu
sankcija, pri ĉemu treba uzeti u obzir da do povrede ove usaglašenosti
moţe doći zbog nedovoljne obuke, neznanja ili sluĉajne akcije korisnika,
[9].

- 339 -
Program zaštita treba da sadrţi izjavu kojom se obavezuju odgovorna lica
na izradu svih internih dokumenata zaštite: Plan zaštite, Politike zaštite i
Procedure zaštite, [1], [6], [10]. Opis funkcionalnog modela programa i
plana zaštite i upitnik za izradu plana zaštite dati su u PRILOGU II 6A.

Treba pomenuti da neki standardi (NIST, na primer) Plan zaštite

smatraju kljuĉnim dokumentom programa zaštite. Plan zaštite obuhvata
politike i procedure zaštite. Ovaj pristup stvara konfuziju kod nekih
autora, koji mešaju Politiku zaštite na nivou organizacije (ili Programsku
politiku) i Plan zaštite. Da bi se to izbeglo, pod Planom zaštite treba
podrazumevati plan za implementaciju politika i procedura programa
zaštite.

- 340 -
1.1. Proces razvoja i struktura plana zaštite

Generiĉki proces razvoja plana zaštite obuhvata pet osnovnih

faza: iniciranje projekta, razvoj politika zaštite, konsultacije i
odobravanje, razvoj svesti i obuka, distribucija politika zaštite, (Sl. 1.1),
[9].

Projektni tim

1.F: Iniciranje
projekta

Nadzorni organ za
projekat zaštite

2.F: Razvoj Konsultacije Zainteresovane

politika zaštite strane

3.F: Konsultacije i Konsultacije

Upravljanje
odobravanje

Program obuke
4.F: Razvoj svesti i i razvoja svesti Organizacione
obuke jedinice

5.F: Distribucija Organizacione

politika jedinice

Sl. 1.1. Generiĉki proces razvoja plana zaštite

Plan zaštite, koji treba da bude dokument organizacije, obezbeĊuje

implementaciju politika i procedura zaštite i mora biti, [12]:

 usklaĊen sa zakonskim propisima,

 usklaĊen sa politikama i procedurama zaštite,
 konzistentan sa planom poslovanja (biznis planom) i poslovnim
procesima,
 usklaĊen sa poslovnim ciljevima i planom razvoja organizacije i
 usklaĊen sa arhitekturom IKT sistema

Osnovna struktura plana zaštite moţe imati generiĉku formu tipiĉnog

poslovnog plana, ali svaki konkretni plan zaštite mora biti jedinstven,
odraţavajući specifiĉnost poslovnih procese, kulturu rada organizacije,
ţivotni ciklus podataka i informacija, zakonske i ugovorne obaveze i

- 341 -
raspoloţivu tehnologiju za zaštitu IKT sistema konkretne organizacije.
Generiĉka struktura plana zaštite sadrţi dve kljuĉne komponente:

- Uloge i odgovornosti i
- Upravljanje promenama (plan kontrola zaštite za upravljanje
promenama).

Uzorci za izradu plana zaštite brojni su i mogu se naći na Internetu u

bazama znanja i standardima zaštite. MeĊutim, retko se moţe naći
objavljen konkretan plan zaštite, jer se smatra autorskim delom i
predstavlja poverljiv dokument za svaku organizaciju.

1.1.1. Uloge i odgovornosti

Uloge i odgovornosti u sistemu zaštite, u strukturi plana zaštite IKT

sistema organizacije, moraju se razvijati na odgovarajućim opšte
prihvaćenim principima zaštite (GAISP) i posebno pripisivati
korisnicima na tri nivoa organizacije i to na nivou, [9], [10], [1]:

 upravne strukture i upravnih odbora organizacija,

 internog rukovodstva organizacije i
 ostalog zaposlenog osoblja.

Uloga uprave/upravnog odbora u izradi i realizaciji plana zaštite je da

obezbedi superviziju i definiše i upravlja glavnim smernicama politike
zaštite, nadzire i kontroliše realizaciju plana zaštite. Praksa je potvrdila
da plan zaštite, kojeg uglavnom prave glavni administratori
mreţe/sistema i administratori zaštite, a nije rezultat projekta
organizacije, ima niz nedostataka (nedovoljno obuhvaćeni procesi rada,
izostavljeni pravni i kulturološki aspekti, aspekti politike upravljanja i
razvoja organizacije, i dr.). U promeni ove loše prakse najbolje rezultate
daju zakonski propisi koji obavezuju uprave i upravne odbore da
preuzmu vodeću ulogu i odgovornost u kreiranju programa, plana i
politika zaštite IKT sistema u svojim organizacijama. U skladu sa
pozitivnim zakonima zaštite u većini drţava, dve osnovne duţnosti
upravne strukture su nametanje prakse:

 obaveznog uvoĊenja standarda u oblast zaštite IKT sistema i

 angaţovanja odgovornih, struĉnih i iskusnih lica na poslovima
zaštite.

- 342 -
Da bi ta odgovornost bila zasnovana na legalnim zahtevima, potrebno je
da u redovnoj poslovnoj praksi upravna struktura dobija pravovremene,
adekvatne i kvalitetne informacije o stanju sistema zaštite i usklaĊenosti
prakse zaštite sa procedurama i politikom zaštite i da je to regulisano
internim dokumentima organizacije. Praksa je pokazala da organizacija,
u sluĉaju napada, spolja ili iznutra, gubi poslovno poverenje, promet i
poslovanje, pa je jasno da navedena odgovornost rukovodstva mora biti
eksplicitna, što je u skladu i sa opštim (GAISP) principima zaštite, [10].
Dobra praksa je da se na nivou borda direktora izabere telo koje ima
zadatak supervizije i kontrole procesa upravljanja bezbednosnim rizikom
i odgovornost za ukupni sistem bezbednosti i zaštite objekata i personala
IKT sistema. Kako se sve više briše granica izmeĊu tradicionalne fiziĉke
i tehniĉke zaštite, a sistemi logiĉke i fiziĉke kontrole pristupa
konvergiraju pojavom tehnologije smart kartica, integralni sistem zaštite
kontroliše većinu fiziĉkih pristupa objektima, vrši identifikaciju i
autentifikaciju u IKT sistemu, povezuje video nadzor i protivprovalnu i
protivpoţarnu zaštitu, a primenom beţiĉnih tehnologija centralizovani
operativni komandni centar moţe neprekidno biti pod kontrolom vlasnika
sistema.

Za izvršavanje supervizorske uloge u zaštiti objekata IKT sistema,

uprava organizacije mora detaljno razmatrati niz pitanja iz sledećih
oblasti:

 Priprema i planiranje za razvoj programa i sistema zaštite;

 Izrada programa zaštite, klasifikacija objekata IKT sistema, analiza
rizika;
 Interna kontrola i nadzor sistema zaštite;
 Implementacija programa i politika zaštite i
 UsklaĊenosti prakse i programa zaštite.

Uloga internog tima organizacije u upravljanju programom zaštite je

odgovornost za stvarni razvoj i reviziju plana, politika i procedura zaštite
i dnevnu analizu rizika. Ĉlanovi ovog tima generalno su rukovodioci
organizacionih jedinica (radnih procesa), predstavnik kadrovske sluţbe,
pravnik, tehniĉko lice koje poznaje tehnološke procese rada, PR
organizacije i glavni rukovodilac sistema zaštite, koji je ujedno lider
tima. Kad je program zaštite implementiran, tim treba da se sastaje svaka
4 meseca i razmatra sledeća pitanja: usklaĊenost prakse zaštite i politika i
procedura zaštite, nadzor i kontrolu sistema zaštite, upravljanje

- 343 -
incidentom, upravljanje vanrednim dogaĊajem i mere za oporavak i
kontinuitet poslovanja, eventualnu reviziju programa zaštite i druga
pitanja.

Primenjujući opšte prihvaćene (GAISP) principe upravljanja rizikom i

najbolju praksu zaštite (ISF - Internet Security Forum, V.4.0), ISA
(Internet Security Alliance) je 2002. godine objavila je 10 glavnih
preporuka za definisanje odgovornosti izvršne upravne strukture
organizacije u odnosu na sledeće komponente zaštite, [1], [7]:

1. Program zaštite. Glavni menadţeri moraju pitanja bezbednosti i zaštite

smatrati normalnim delom svojih odgovornosti i odgovornosti svih
zaposlenih. Oni treba da definišu i odrede ulogu sistema bezbednosti i
zaštite u organizaciji, odgovornosti svih zaposlenih i da obezbede
adekvatno finansiranje zaštite. Moraju eksplicitno ispoljiti liderstvo
(pismeno i usmeno na sastancima), kreirati, nametati i regularno
revidirati i kontrolisati program zaštite.

2. Politika zaštite. Razvijati, implementirati, kontrolisati i nametati

primenu politika zaštite koje doprinose postizanju poslovnih ciljeva.
Politike zaštite treba da obuhvate kljuĉne oblasti kao što su: upravljanje
bezbednosnim rizikom, identifikacija kritiĉnih objekata, fiziĉka zaštita,
upravljanje raĉunarskim sistemima i mreţama, autentifikacija i
autorizacija, kontrola pristupa, upravljanje vanrednim dogaĊajima, zaštita
poverljivosti, integriteta i raspoloţivosti, upravljanje incidentima,
podizanje svesti o potrebi zaštite i obuka, sertifikacija i akreditacija
sistema zaštite. Rukovodilac se mora uveriti da je svaka politika zaštite
koncipirana u skladu sa standardima i principima, da sadrţi procedure sa
najboljom praksom zaštite, kao i zahteve za obuku i optimalnu
arhitekturu sistema zaštite.

3. Upravljanje rizikom. Periodiĉno vršiti analizu i procenu rizika da bi se

identifikovali kritiĉni objekti, pretnje, faktori rizika i ranjivosti sistema.
Razviti i implementirati plan ublaţavanja rizika do kontrolisanog i
prihvatljivog nivoa i vršiti redovnu kontrolu.

4. Projektovanje arhitekture sistema zaštite. Projektovati, implementirati

i odrţavati u organizaciji sveobuhvatni, integralni, modularni i skalabilni
sistem zaštite, ĉija se arhitektura zasniva na poslovnim ciljevima i
potrebama zaštite kritiĉnih objekata. Razviti višeslojnu arhitekturu

- 344 -
sistema proaktivne zaštite za otvorene, visoko distribuirane IKT sisteme
(OSI modela) i slojevit pristup zaštiti, na primer, zaštiti mreţe, hostova,
aplikacija, podataka, ukljuĉujući procedure i praksu zaštite koja sledi.
Koristiti raznovrsna i redundantna rešenja, kao što su: autonomni izvori
napajanja, telekomunikacije otporne na prisluškivanje i presretanje
informacija, poverljivi hardver raĉunarskih sistema, OS sa otvorenim
izvornim kodom i pouzdane aplikacije za visoko pouzdan sistem zaštite,
otporan na visoke faktore rizika.

5. Korisnici sistema. Uspostaviti odgovornosti za sve akcije korisnika

koji imaju naloge za pristup IKT sistemu i implementirati ih kroz politiku
i procedure zaštite, nametanje obaveze izvršavanja i obuku. Obezbediti
adekvatnu internu ili poverljivu, ugovornu ekspertsku podršku za sve
tehnologije zaštite, ukljuĉujući i obezbeĊenje funkcionisanja tih
tehnologija.

6. Funkcionalna pouzdanost IKT sistema. Uspostaviti ĉitav niz kontrola

pristupa objektima zaštite i kontrola za obezbeĊivanje funkcionalne
pouzdanosti objekata i IKT sistema u celini. Regularno verifikovati
integritet instaliranih sistemskih i aplikativnih programa. Obezbediti
procedure i mehanizme za zaštitu u celokupnom ţivotnom ciklusu
sistema, ukljuĉujući vreme instalacije, eksploatacije, odrţavanja i
povlaĉenja iz upotrebe.

7. Autentifikacija i autorizacija. Implementirati i odrţavati mehanizme za

autentifikaciju (verifikaciju identiteta) i autorizaciju (davanje ovlašćenja)
prava pristupa objektima IKT sistema i obezbediti konzistentnost sa
politikom, procedurama i odgovornostima za specifiĉne objekte. Posebno
zaštititi kritiĉne objekte kada se obezbeĊuje daljinski pristup i pristup
nepoverljive treće strane.

8. Nadzor i kontrola (audit). Uspostaviti kapacitete i koristiti

odgovarajući sistem za nadzor i kontrolu zaštite i alate za merenje
usklaĊenosti sa politikom i procedurama zaštite. Dodeliti odgovornosti za
evaluaciju, izveštavanje i interventne odgovore na bezbednosne
kompjuterske incidente. Obezbediti da svi zaposleni znaju koga treba
kontaktirati u sluĉaju sumnjivog ponašanja u sistemu.

- 345 -
9. Fizička zaštita. Kontrolisati fiziĉki pristup objektima, informacijama,
servisima i kritiĉnoj hardverskoj opremi IKT sistema, kroz sisteme
kontrole pristupa kakvi su biometrijski, smart kartice, bedţevi, kljuĉevi,
lozinke, kontrolisane elektronske brave za radne stanice, servere i lap-top
raĉunare.

10. Planiranje kontinuiteta poslovanja i oporavka sistema. Razviti ove

planove, verifikovati ih, periodiĉno i regularno testirati i obezbediti
njihovu efikasnu primenu.

Uloga korisnika: Plan zaštite poĉinje da ţivi kroz aktivnosti ljudi koji
implementiraju politiku zaštite instalacijom mehanizama i protokola i
primenom procedura zaštite. Od fiziĉkog obezbeĊenja do izvršioca
tehnoloških poslova i menadţera, svi zaposleni treba da se smatraju
dragocenim uĉesnicima u razvoju plana, politike i procedura zaštite.
Zaposleni koje koristi tehnologije u radnim procesima znaĉajni su za
zaštitu, jer najbolje poznaju poslovne procese, razumeju šta dobro radi, a
šta ne radi, ko zna gde su ranjivosti sistema i ko moţe obezbediti
dragocene ulazne podatke za proces planiranja zaštite. Pored toga
konsultovani zaposleni cene što ih neko pita za mišljenje i smatraju se
delom procesa pa je lakše izgraditi i svest o potrebi zaštite u edukativnom
procesu i obezbediti visoku korisniĉku prihvatljivost procesa zaštite.
Korisnici lakše podrţavaju program zaštite i shvataju da je zaštita vaţan
elemenat ukupnih poslova.

1.1.2. Upravljanje promenama

Upravljanje promenama definiše se kao sistemsko uvoĊenje

promena bilo koje vrste u kompleksan IKT sistem. Zato svaki plan zaštite
IKT sistema treba da obuhvati faktore promena okruţenja (faktora rizika
sa velikim stepenom neodreĊenosti), tehnologija zaštite, OS, hardvera
raĉunarske opreme, konfiguracije mreţa, radnog prostora, aplikacija i.t.d.
Neophodno je da plan zaštite obuhvati upravljanje promenama, što nije
samo zahtev opštih GAISP principa za efikasnom zaštitom, nego treba da
bude i mandatna obaveza, jer je glavna namena procesa kontrole
promena da upravlja promenama u kompjuterskom okruţenju.

Plan, politike i procedure zaštite obavezno se moraju regularno revidirati

u skladu sa promenama. Rutinski poslovi i tehniĉke operacije utiĉu na
bezbednosno okruţenje i unose promene, kao što su: oĉvršćavanje OS

- 346 -
(aplikacija bezbednosnih popravki-„zakrpa―), instalacija novih aplikacija
i OS, modernizacija opreme i.t.d. U operativnom okruţenju, bezbednosno
relevantne promene mogu uneti novi informacioni tokovi, promene u
poslovnim odnosima, nova organizaciona struktura i novi legalni i
administrativni zahtevi. Za upravljanje promenama treba primenjivati
opštu proceduru za upravljanje promenama sa sledećom strukturom:

 uvoĊenje promena,
 kataloška registraciju promena,
 planski raspored promena,
 implementacija promena i
 izveštavanje upravne strukture o izvedenim promenama.

Za svaku komponentu plana zaštite, mora se zaduţiti po jedno lice da

upravlja promenama u skladu sa pridruţenom politikom i procedurama
zaštite. Plan zaštite treba da sadrţi sistem upravljačkih, operativnih i
tehničkih kontrola zaštite koje treba primenjivati za kontrolu tehniĉkih,
operativnih, organizacionih, personalnih i normativnih promena, kao i
promena u fiziĉkom okruţenju, koje sve utiĉu na komponente plana
zaštite. Ovaj deo plana zaštite je od presudnog znaĉaja za pripremu i
planiranje projektovanja arhitekture sistema zaštite.

Model generiĉke strukture detaljnog Plana zaštite opisan je u PRILOGU

II 6B, a dva tipa uzoraka strukture Plana zaštite prikazana su u
PRILOGU II 6C, [11]. Drugi tip uzorka Plana zaštite u PRILOGU II
6C usklaĊen je sa konceptom kontrola zaštite, mapiran sa odgovarajućim
familijama zaštite, pregledniji i ima veću korisniĉku prihvatljivost.

- 347 -
1.2. Struktura politika i procedura zaštite

1.2.1. Definicija i namena politike zaštite

Politika zaštite je kljuĉni dokument programa i plana zaštite.

Politike i procedure zaštite obuhvataju skup informacija iz oblasti zaštite,
koje treba dokumentovati u organizaciji. Politika zaštite (bezbednosna
politika) je dokument koji navodi bezbednosne ciljeve (ciljeve zaštite)
organizacije u odnosu na odreĊene oblasti delovanja. Generalno, politika
zaštite je izjava na odreĊenom nivou apstrakcije koja govori šta treba
raditi u kompleksnoj oblasti zaštite. Razvoj politike zaštite ĉesto
podrazumeva i razvoj odgovarajućih procedura zaštite. Procedura zaštite
je izjava koja ukratko navodi kako nešto treba uraditi u oblasti zaštite.
Procedure zaštite obuhvataju metode kojima se postiţu bezbednosni
ciljevi navedeni u politici zaštite, ukljuĉujući redosled izvršavanja
aktivnosti u identifikovanim procesima zaštite, [9].

Politike i procedure zaštite zajedno definišu naĉine obezbeĊivanja,

korišćenja, odrţavanja i odlaganja resursa zaštite u organizaciji. Na
primer, Politika personalne zaštite, obezbeĎuje osoblje u zaštiti -
zapošljavanjem, održava zaštitu personala - motivisanjem i odlaže isti
resurs - penzionisanjem ili raskidom ugovora.

Politika zaštite, kljuĉna je komponenta plana zaštite, obezbeĊuje okvir

oĉekivanog i obaveznog ponašanja upravne strukture, zaposlenih,
tehnologije i procesa; utvrĊuje ciljeve organizacije, oĉekivanja i
verifikovane korisniĉke zahteve, a koristi metodološke kategorije kao što
su instrukcije, procedure, pravci aktivnosti i principi rada, koje su
obavezne za organizaciju. Upravljanje integralnim sistemom zaštite
zahteva artikulaciju u dokumentovanoj zvaniĉnoj politici koja striktno
podrţava plan zaštite. Politika zaštite ima nekoliko funkcija:

 obezbeĊuje okvir za donošenje odluka u oblasti zaštite,

 prilagoĊava se specifiĉnim situacijama kroz odgovarajuće procedure i
uputstva,
 obezbeĊuje standarde, najbolju praksu i preporuke za ispunjenje
plana zaštite,
 integriše priznate standarde i najbolju praksu zaštite informacija,

- 348 -
 obezbeĊuje usvajanje standarda i osnovu za evaluaciju (merenje,
nadzor i kontrolu i validaciju) usaglašenosti prakse i programa
zaštite,
 u sluĉaju spora zbog zloupotreba IKT i/ili kompjuterskog kriminala,
obezbeĊuje dokaz pred sudom da su mere zaštite bile
implementirane, aktivne i da odgovaraju najboljoj praksi i
standardima zaštite.

1.2.2. Taksonomija politika zaštite

Politika zaštite moţe se formirati iz zakona i standarda, kao i

poslovnog i ţivotnog iskustva zaposlenih u organizacijama i njihovih
saradnika. Generiĉka struktura Politike zaštite obuhvata tri glavne
strukturne komponente, [6 ], [10], [12]:

1. sadržaj (bezbednosne ciljeve),

2. zahteve za usklaĎenost i monitoring i
3. komponente prinude.

Zavisno od nivoa apstrakcije i namene, politike zaštite mogu se izraditi

na nivou:
1. organizacije (Organizacijska politika zaštite),
2. radne funkcije organizacije (Funkcionalna politika zaštite),
3. IKT sistema (Sistemska politika zaštite) i
4. komponenti i sistema zaštite (Politike komponente/sistema
zaštite).

Organizacijska politika zaštite obuhvata bezbednost rada organizacije i

moţe obuhvatiti: prihvatljivost korišćenja tehnologije zaštite e-pošte,
beţiĉnih sistema veza i daljinskog pristup; zaštitu i nepovredivost
intelektualne svojine; upravljanje bezbednosnim rizikom u IKT sistemu;
upravljanje vanrednim dogaĊajem i kompjuterskim incidentom i
obezbeĊenje kontinuiteta poslovanja. Svaki navedeni elemenat
organizacijske politike zaštite treba napisati koncizno i razumljivo, da
eksplicitno obavezuje (nameće obavezu izvršavanja) i da je statiĉan tj.
relativno nepromenljiv u datom vremenskom periodu.

Primer: U Politici za Upravljanje rizikom uprava treba da: definiše cilj,

obim i tim za analizu i procenu rizika sa eksplicitno navedenim
odgovornostima; sugeriše metod analize i procene rizika (sopstvenim i/ili

- 349 -
iznajmljenim resursima); odredi dinamiku i plan nadzora i kontrole
procesa upravljanja rizikom i da odobri prihvatljivi nivo preostalog
rizika.

Funkcionalna politika zaštite obuhvata specifiĉne poslovne funkcije

organizacija. U zavisnosti od kulture organizacije, treba ukazati
poverenje svakom zaposlenom za odreĊenu ulogu u zaštiti. Ova politika
mora biti napisana tako da je istovremeno uputstvo za zaposlene sa
odgovorima na sva pitanja iz oblasti zaštite i procesa bezbednosne
klasifikacije objekata IKT sistema i da obezbeĊuje „balans zaštite i
produktivnosti―. Predlog i nacrt politike treba da izradi tim odreĊen za taj
zadatak, sastavljen od funkcionalnih rukovodioca poslovnih procesa.
Funkcionalna politika zaštite treba da navede razloge zašto je politika
potrebna, opiše funkcije koje pokriva, definiše odgovornosti i kontakte i
predloţi kako će se tretirati povrede politike.

Primer: Zdravstveni informacioni sistem (ZIS) zahteva brojne

funkcionalne promene za usklaĊivanje sa normativima za zaštitu
zdravstvenih i liĉnih podataka pacijenata. Funkcionalna politika zaštite u
ZIS treba da: postavi u prvi plan koji podaci i informacije moraju biti
raspoložive za odreĊeni krug korisnika, koje posebno zaštićene, a koje
specificirane za pristup i rukovanje samo odreĊenim licima; definiše
kako podatke i informacije treba šifrovati i na koje odreĊene destinacije
slati.
Politika zaštite na nivou IKT sistema uspostavlja standarde za IKT
okruţenje, kao što su specifikacija uslova za: obezbeĊenje raspoloţivosti
mreţnih servisa, bezbedne mreţne infrastrukture i pouzdanosti rada;
namenu zaštitnog softvera hosta i raĉunarske mreţe; uspostavljanje
standarda kriptozaštite za PC i LapTop raĉunare, zaštitu komunikacija,
kao i specifikaciju zahteva za upravljanje kompjuterskim incidentom,
vanrednim dogaĊajem, nastavljanje poslovanja i oporavak sistema i.t.d.
Primer: Politika upravljanja konfiguracijom (administracije) IKT
sistema treba da:
 definiše metode testiranja novog hardvera/softvera,
 definiše metode instalacije i neophodnu dokumentaciju,
 sugeriše proces upravljanja svim promenama,
 identifikuje pravo vlasništva nad sistemom i
 definiše ovlašćenja za izmenu konfiguracije.

- 350 -
Politika zaštite na nivou sistema zaštite obezbeĊuje osnovni skup
elemenata za definisanje bezbednosnih zahteva za dnevno operativno
upravljanje sistemom zaštite, kao što je: kontrola sadrţaja pasvorda,
korišćenje tehnologija za autentifikaciju i autorizaciju i.t.d.

Primer: politika zaštite u ZIS koja se odnosi na zaštitu zdravstvenih i

ličnih podataka moţe identifikovati koje osoblje treba da ima pristup
diagnostiĉkim izveštajima, specificirati koji se proces autentifikacije i
autorizacije zahteva, definisati koja se fiziĉka zaštita zahteva (n.p.r. ne
ostavljati izveštaj otvoreno na stolu), kako dijagnostiĉke informacije
treba unositi i kakav kriptološki algoritam treba koristiti, identifikovati
kome je dozvoljeno da se prenesu informacije, sugerisati kako da se
izbegnu uobiĉajene greške i.t.d.

1.2.3. Struktura procedura zaštite

Procedure su precizno definisane aktivnosti i metodi primene

elemenata politike zaštite. Sadrţe detaljne liste i opšte forme koraka i
instrukcija za izvršavanje specificiranih procesa, koje pojedinci moraju
koristiti dok izvršavaju te procese, [1], [10]. U procesnom pristupu
sistemu zaštite procedura zaštite moţe se definisati kao sastavna
komponenta procesa zaštite koja opisuje sekvencijalno izvršavanje
baziĉnih aktivnosti i zadataka, povezuje aktivnosti zaštite, koje ĉini skup
povezanih elementarnih radnji i odreĊuje redosled izvršavanja radnji,
aktivnosti i zadataka, [13]. Znaĉaj procedura zaštite ne sme se nikako
potcenjivati, jer je na osnovi istraţivanja (CompTIA - Computing
Technologies Industry Association, 2003) utvrĊeno da su ljudske greške
primarni uzrok proboja sistema zaštite. Procedure propisuju naĉine
implementacije i operativnog korišćenja mehanizama i protokola zaštite

Primer: Procedura za upravljanje kompjuterskim incidentom, kritiĉan i

jedan od osnovnih elemenata politike zaštite, treba da:

 definiše ko i kako upravlja incidentom,

 kako se istraţuju napadi i anomalije u sistemu,
 kako i kada se interni ili eksterni napad dogodio,
 ko moţe objaviti informacije o incidentu i kome ih dostavljati i
 da naglasi ko i kako treba da izvrši forenziĉku istragu, akviziciju i
analizu digitalnih kompjuterskih dokaza.

- 351 -
Procedure zaštite u upravljaĉkom okviru spuštaju politiku zaštite na
operativni nivo i objašnjavaju praktiĉne korake kakao se implementira
politika zaštite u dnevnom radu. UsklaĊenost prakse i politike zaštite u
velikoj meri zavisi od toga koliko su kompletne procedure i koliko dobro
definišu i opisuju zadatke koje treba preduzeti da bi se ispunili
bezbednosni zahtevi politike zaštite, [9].

Na primeru komponente Programa zaštite zdravstvenog informacionog

sistema ova dokumenta bi mogla obuhvatiti sledeće sadrţaje:

1. Plan zaštite: Poboljšati zaštitu tajnosti i poverljivosti elektronskog

zdravstvenog kartona (EZK) korišćenjem servisa autorizacije prava,
autentifikacije korisnika i softverskog sistema kriptozaštite podataka i
komunikacija.

2. Politika zaštite: Mehanizam logičke kontrole pristupa (AC) treba da

dopušta pristup samo ovlašćenim korisnicima ĉiji se identitet
autentifikuje. Pristup EZK moţe biti samo sa lokacije odeljenja
zdravstvene ustanove. OdreĊene informacije koje identifikuju liĉne ili
zdravstvene podatke pacijenata moraju biti kriptozaštićene u bazama
podataka i na komunikacionim linijama.

3. Procedure zaštite treba da definišu:

 spisak osoblja sa pravima (ovlašćenjima) za pristup elektronskom

zdravstvenom kartonu (EZK),
 tehnologiju (mehanizam za kontrolu pristupa) zaštite koja će se
koristiti za identifikaciju i autentifikaciju (npr. pasvord, biometrijski
identifikator, smart kartica, i dr.),
 specifiĉno polje ZEK koje treba šifrovati (na primer, matiĉni broj
pacijenta), kojim sistemom kriptozaštite i kako,
 restrikcije u pogledu otkrivanja podataka iz EZK bilo kojem licu ili
entitetu, osim onim koji su specifiĉno ovlašćeni politikom zaštite,
 naĉin izveštavanja u sluĉaju proboja sistema zaštite i sumnjivog
ponašanja u sistemu.

- 352 -
2. REZIME

Program zaštite ili politika zaštite na najvišem nivou organizacije

obuhvata detaljan i sveobuhvatan plan zaštite, politike i procedure zaštite.
Plan zaštite je sveobuhvatan strategijski dokument za zaštitu objekata
IKT sistema. Politika zaštite je kljuĉna komponenta plana zaštite;
predstavlja izjave na visokom nivou, koje obezbeĊuju okvir oĉekivanog i
obaveznog ponašanja upravne strukture, zaposlenih, tehnologije i procesa
u sistemu zaštite, a realizuje se kroz instrukcije, procedure, pravce
aktivnosti i principe rada koji su obavezni za celu organizaciju.
Procedure zaštite su precizno definisani naĉini izvršavanja aktivnosti i
prakse zaštite u primeni elemenata politike zaštite sa listom detalja i
opštih formi redosleda koraka specificiranih procesa, koje pojedinci
moraju primenjivati dok izvršavaju te procese. Procedure propisuju
naĉine implementacije i operativnog korišćenja mehanizama i protokola
zaštite.

Osnovni zahtevi programa zaštite su sprovoĊenje nacionalnih i EU

primenljivih zakona i standarda za zaštitu i za borbu protiv zloupotreba
IKT i kompjuterskog kriminala, kao i za istragu, akviziciju, analizu i
veštaĉenje digitalnih dokaza za pravosudne potrebe. Razvoj svesti o
potrebi i obuka u oblasti zaštite kljuĉne su komponente za
implementaciju i odrţavanje efektivnog programa zaštite. Plan stvaranja
svesti o potrebi zaštite i obuka u oblasti zaštite treba da obuhvati sve
kategorije zaposlenih.

Nametanje obaveze izvršavanja elemenata politike zaštite i izveštavanja

o preduzetim aktivnostima kritiĉna je komponenta programa zaštite, jer
ako nema posledica za povrede politike zaštite, zaposleni je neće
dosledno sprovoditi.

U implementaciji programa zaštite i projektovanju arhitekture sistema

zaštite najznaĉajnije su procene znaĉaja tehnološkog aspekta zaštite,
uticaja internih i eksternih pretnji, faktora operativnog rada, regulativa,
organizacione strukture i sistema upravljanja. Brojne organizacije
smatraju da kombinovanje i sinhronizacija tehniĉkih aspekata zaštite sa
upravljaĉkim (zakonskim, normativnim) i organizacionim predstavlja
veliki problem. U projektovanju i razvoju programa zaštite cilj je da se
identifikuju tehnologije i alati koji mogu rešiti ili pomoći proces
implementacije programa zaštite.

- 353 -
3. KLJUĈNI TERMINI

Digitalni objekti: informatiĉki objekti koji obuhvataju podatke i

informacije; programe i aplikacije; servise; raĉunarski i mreţni hardver
koji procesiraju, skladište i prenose podatke i informacije.
Plan zaštite: sveobuhvatan dovoljno detaljan, jasan i precizan dokument
za planiranje zaštite objekata IKT sistema. Dokument Plana zaštite
obuhvata Politike i Procedure zaštite.
Politika zaštite: komponenta plana zaštite, izjava na visokom nivou koja
obezbeĊuje okvir oĉekivanog i obaveznog ponašanja upravne strukture,
zaposlenih, tehnologije i procesa kroz instrukcije, procedure, pravce
aktivnosti i principe rada koji su obavezni za organizaciju; naĉin na koji
neki entitet (organizacija, institucija) upravlja, štiti i distribuira poverljive
podatke i informacije; definiše ko moţe imati pristup kojoj informaciji i
koje aktivnosti moţe obavljati: ĉitanje, pisanje, dodavanje i brisanje
podataka; obezbeĊuje meĊusobno poverenje uĉesnika, što je od
fundamentalnog znaĉaja.
Procedure zaštite: precizno definisani naĉini primene elemenata politike
zaštite sa listom detalja i opštih formi koraka specificiranih procesa koje
pojedinci moraju koristiti dok izvršavaju te procese; spuštaju politiku
zaštite na operativni nivo i objašnjavaju kakao se implementira politika
zaštite za dnevni rad; usklaĊenost prakse i politike zaštite u velikoj meri
zavisi od toga kako su kompletne procedure i koliko dobro definišu i
opisuju radnje koje treba preduzeti da bi se zadovoljili bezbednosni
zahtevi.
Program zaštite: sve što neka organizacija ĉini da proizvede, primeni,
podrţi i unapredi bezbednost IKT sistema; programska politika zaštite na
najvišem nivou, koja predstavlja smernice za izradu detaljnog plana,
politike i procedura zaštite.

- 354 -
4. LITERATURA

1. American Bar Association, Section of Science &Technology

Law, Privacy & Computer Crime Committee, International
Strategy for Cyberspace Security,
www.abanet.org/abapubs/books/cybercrime/, 2003.
2. CERT Coordinating Center, Security of the Internet,
―Firewalls,‖, Carnegie Mellon University, Software
Engineering Institute,
http://www.cert.org/firewalls_notes/index.hatml, 2003.
3. Harold F. Tipton, Micki Krause: The information security
handbook, 4th izdanje vol.2.CRC Press LLC, 2001.
4. http://www.cert.org/incident_notes/index.html.
5. http://www.first.org/team-info.
6. http://www.sans.org/politics.html.
7. ISF, The Standard for Good Practice for Information
Security, http://www.isf.org, V.3.0., 2003.
8. Karygiannis L. O., Wireless Network Security: 802.11,
Bluetooth and Handheld Devices, NIST SP 800-48,
http://www.nist.gov/publications, novembar 2002.
9. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII.
decembar, 2005.
10. NIST SP 800-12, An introduction to computer Security- The
NIST Handbook, , http://www.nist.gov/publications, 1997.
11. NIST SP 800-14, Genaerally Accepted Principles and
Practices for Security, http://www.nist.gov/publications,
2002.
12. NIST SP 800-18, Guide for Developing Security Plans for IT
Systems, http://www.nist.gov/publications,1998/2005.
13. Purser S., A practical Guide to Managing Information
Security, Artech House, Boston-London,
www.artechhouse.com, 2004.
14. RFC 2196, Site Security handbook,
http://www.faqs.org/rfc/rfc2196.html, 1997.
15. Stoneburner G., Hayden C. and Feringa A., Engineering
Principles for Information Technology Security (A Baseline
for Achieving Security), NIST SP 800-27,
http://www.nist.gov/publications, 2004.

- 355 -
16. The Canadian Handbook on Information Technology (IT)
Security, www.canada.gov.itsec.com, 1999.
17. www.cs.dartmouth.edu/~farid/publications/tr01.pdf.
18. www.isa.com, 2002.
19. www.isaca.com, 2003.

- 356 -
7. RAZVOJ POLITIKA I PROCEDURA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja:

- razumećete principe i model za izradu politika zaštte

- moći ćete samostalno razviti Politiku zaštite (org., IS, ...)
- moći ćete samostalno razviti Proceduru zaštite

Politika zaštite je kljuĉni dokument programa zaštite koji sadrţi

bezbednosne ciljeve organizacije u odnosu na odreĊenu oblast/
komponentu sistema zaštite kroz skup izjava o tome ŠTA treba raditi u
oblasti zaštite i skup pravila za pristup i bezbedno korišćenje informacija
i IKT sistema organizacije. Procedure zaštite navode više detalja i govore
o tome KAKO nešto treba uraditi.

Proces razvoja i odrţavanja upotrebljivih standarda, uputstava, politika i

procedura zaštite ili kljuĉnih elemenata kontrolnog okvira za upravljanje
zaštitom, izuzetno je vaţan, ako se sa merama i metodama zaštite ţele
postići ţeljeni bezbednosni ciljevi definisani u programu zaštite.

Najbitniji zahtevi u procesu izrade standarda, uputstava, politika i

procedura zaštite su: jasno razumevanje vizije i ciljeva zaštite od strane
menadţerske strukture; ukljuĉivanje i proces izrade politike zaštite
specijalista zaštite u IKT sistemu, informatiĉara i što je moguće više
predstavnika organizacionih jedinica (tehnoloških procesa, pravne i
kadrovske sluţbe) i jasna artikulacija standarda, uputstava, politika i
procedura zaštite na koncizan i praktiĉan naĉin i da reflektuju potrebe
organizacije.

Ako se sledi ovaj pristup razvoja kontrolnog okvira, mnogo je veća

verovatnoća da će se implementacijom dostići realni set standarda,
uputstava, politika i procedura zaštite. Ovakav pristup će takoĊe olakšati
korisniĉku prihvatljivost razliĉitih organizacionih jedinica i individualnih
korisnika koji imaju osećaj da su vlasnici procesa, bolje ih razumevaju i
iste više podrţavaju. TakoĊe, mnogo se lakše nameće sistem zaštite i
izvršavaju aktivnosti nadzora i kontrole.

- 357 -
Osnovna namena politika zaštite je da informišu korisnike IKT sistema,
tehniĉku podršku i menadţment organizacije o zahtevima za zaštitu
sistema i informacija i da obezbede uputstva za nabavku, konfigurisanje,
praćenje funkcionisanja i zaštićenosti, bezbednosnu kontrolu i
upravljanje objektima IKT sistema.

Menadţment organizacije implementira i podstiĉe sprovoĊenje politika

zaštite, a bezbednost IS je, zapravo, u rukama zaposlenih koji zaštićene
sisteme svakodnevno koriste.

Brojne politike zaštite mogu se izraditi u okviru politike zaštite IKT

sistema ili politike zaštite na nivou sistema zaštite, ali mogu biti i
samostalni dokumenti.

- 358 -
1. METODOLOGIJA ZA IZRADU POLITIKE ZAŠTITE

1.1. Praktiĉni principi za dizajniranje Politike zaštite

Za razvoj i implementaciju politike zaštite korisno je primenjivati

sledeće principe, [14]:

1. Obezbediti »bezbednost« greške: ako se greška dogodi, IKT

sistem treba da padne na bezbedan naĉin, što znaĉi sistem zaštite
treba da ostane u funkciji, odnosno, bolje izgubiti funkcionalnost
nego bezbednost.
2. Evidentiranje bezbednosnih dogaĎaja: Kada su sistem i mreţa
kompromitovani, treba registrovati ili evidentirati u log datoteci
tu kompromitaciju. Ove informacije mogu pomoći kod
identifikacije naĉina iskorišćenja ranjivosti i identifikacije
napadaĉa.
3. Jednostavnost rešenja: mehanizmi zaštite i IKT sistem generalno
treba da bude što je moguće jednostavniji. Kompleksnost je uzrok
brojnih bezbednosnih problema.
4. Jednostavnost upravljanja: samo se u jednostavno i lako
upravljanom sistemu moţe efikasno proveriti usaglašenost
konfiguracije raznih komponenti i ostvariti zahtevano centralno
upravljanje.
5. Minimizacija privilegija: predstavlja dodeljivanje samo onih
korisniĉkih i adminstrativnih prava pristupa koja su neophodna za
izvršavanje duţnosti.
6. Nedopustivost prelaska sistema u nebezbedno stanje: što znaĉi
da pod oĉekivanim okolnostima sistem zaštite ili potpuno
izvršava svoje funkcije ili potpuno blokira pristup.
7. Nemogućnost zaobilaženja mehanizama zaštite: podrazumeva da
svi informacioni tokovi u zaštićenoj mreţi i iz nje, moraju
prolaziti kroz sistem zaštite informacija. Ne moţe biti tajnih
modemskih izlaza ili linija za testiranje koje izlaze izvan mreţne
barijere.
8. ObezbeĎenje sveopšte podrške zaštite: preporuĉuje se opštim
principima preduzimanja sveobuhvatnih mera zaštite usmerenih
na obezbeĊivanje podrške i prihvatljivosti kroz teoretsku i
praktiĉnu obuku i dobru praksu zaštite.
9. Odvajanje dužnosti: pretpostavlja takvu raspodelu uloga i
odgovornosti u sistemu zaštite i IKT sistemu, u kojoj jedan ĉovek

- 359 -
 ne moţe narušiti kritiĉne procese organizacije. Ovaj princip je
posebno znaĉajan za spreĉavanje malicioznih ili neovlašćenih
aktivnosti administratora sistema.
10. Odvajanje privilegija: funkcije u zaštiti do najvećeg mogućeg
stepena treba da budu odvojene. Koncept treba primeniti i na
sisteme i operatere/korisnike. Na primer ako resursi dopuštaju
ulogu sistem administratora treba odvojiti od uloge administratora
zaštite.
11. Otvoreni dizajn arhitekture sistema zaštite: sistem zaštite ne
treba da zavisi od tajnih implementacija komponenti zaštite, jer
»bezbednost kroz tajnost« ne moţe biti efikasna.
12. Jačanje zaštite samo slabih komponenti: sigurnost (assurance)
svakog sistema zaštite odreĊena je sa stepenom zaštićenosti
najslabije komponente, što ĉesto nije ni raĉunar ni program, nego
ĉovek, kada problem zaštite poprima netehniĉki karakter.
13. Potpuna posrednost: treba koristiti svuda indirektan pristup
informacijama, preko posrednih elemenata koji nameću politiku
zaštite. Primeri su kontrola pristupa, proxy web server,
autentifikacioni server, e-mail gateway.
14. Primena raznovrsnih mehanizama zaštite: preporuĉuje se
primena mehanizama razliĉitih po svom karakteru (upravljaĉki,
operativni, tehniĉki), da bi maliciozni napadaĉi morali ovladati
razliĉitim i po mogućnosti meĊusobno nespojivim veštinama za
proboj ili zaobilaţenje sistema zaštite.
15. Psihološka korisnička prihvatljivost: korisnici treba da razumeju
potrebu zaštite, što se moţe obezbediti kroz obuku.
Implementirani bezbednosni mehanizmi treba da pruţe
korisnicima osećaj korisnosti koju dnevno zahtevaju. Ako
korisnici smatraju mehanizme zaštite suvišnim opterećenjem naći
će naĉina da ih zaobiĊu i kompromituju. Primer ovoga je
korišćenje sluĉajnih pasvorda koji su vrlo jaki ali teški za
pamćenje, pa ih korisnici zapisuju ili traţe naĉin da zaobiĊu ovu
politiku.
16. Slojevita zaštita: organizacije moraju shvatiti da je svaki
pojedinaĉni bezbednosni mehanizam generalno nedovoljan.
Mehanizmi zaštite treba da budu slojevito rasporeĊeni u
arhitekturi sistema zaštite, tako da kompromitacija jednog ne
ugroţava host sistem ili mreţu. Znaĉi, posle upravljačkih kontrola
moraju slediti organizaciono-operativne i tehničke kontrole
zaštite. Više nivoa zaštite zadrţavaju zlonamernog napadaĉa, a

- 360 -
 poslednji-tehniĉki nivo kontrola zaštite bitno oteţava maliciozne
aktivnosti

1.2. Autori izrade kontrolnog okvira

Zadatak stvarnog pisanja politike, standarda koji je podrţavaju,

uputstava i procedura zaštite, tipiĉno pripada specijalistima za zaštitu u
IKT sistemu, uz pomoć ostalog osoblja u organizaciji. Posebno od
pomoći mogu biti neposredni rukovodioci organizacionih jedinica, kao i
spoljni konsultant, ako specijalisti zaštite nemaju dovoljno iskustva i ako
je vreme kratko.

Spoljni konsultant uglavnom pravi nacrt dokumenata u pripremnoj fazi.

Konaĉan nacrt dokumenata mora se podneti upravnoj strukturi na
odobravanje, pre dostavljanja dokumenata korisnicima. Ako se formira
radna grupa za izradu ovih dokumenata, nacrt joj se mora dostaviti pre
upućivanja upravnoj strukturi. U suprotnom pojedinci iz organizacije
mogu dokumenta smatrati formalno manje znaĉajnim.

Konaĉno dostavljanje dokumenata zaštite treba obaviti na regularan

naĉin, kako se dostavljaju takve informacije u organizaciji: na
odgovarajućem memorandumu organizacije, na sastancima kolektiva i
preko internog oglašavanja.

- 361 -
1.3. Standardi za izradu politike zaštite

Politika zaštite kljuĉna je komponenta plana zaštite. Politika zaštite je

izjava na visokom nivou koja obezbeĊuje okvir oĉekivanog i obaveznog
ponašanja upravne strukture, zaposlenih, tehnologije i procesa; utvrĊuje
ciljeve organizacije, oĉekivanja i verifikovane korisniĉke zahteve, a
koristi metodološke kategorije kao što su principi, instrukcije, procedure i
pravci aktivnosti, koje su obavezne za organizaciju. Upravljanje
integralnim sistemom zaštite zahteva artikulaciju u dokumentovanoj
zvaniĉnoj politici koja striktno podrţava plan zaštite. Politika zaštite ima
nekoliko funkcija, [9], [10]:

 obezbeĎuje okvir za odluĉivanje i upravljanje u oblasti zaštite,

 obezbeĎuje skalabilnost, moţe se doterivati i prilagoĊavati za
specifiĉne situacije kroz odgovarajuće procedure i uputstva,
 obezbeĎuje standard najbolje prakse i preporuke za arhitekturu
sistema i poslovne operacije u skladu sa planom zaštite,
 integriše priznate standarde i najbolju praksu u program zaštite
informacija,
 obezbeĎuje implementaciju standarda i osnovu za evaluaciju
(merenje, nadzor i kontrolu i validaciju) usaglašenosti prakse i
politike zaštite,
 obezbeĎuju sistem kontrolnih identifikatora (benchmark) za zaštitu
od legalne odgovornosti u sluĉaju neuspeha postizanja minimalnog
standarda zaštite,
 obezbeĎuje dokaz pred sudom da su mere zaštite bile
implementirane, aktivne i da odgovaraju najboljoj praksi i
standardima zaštite (ISO 17799, ISO/IEC 13335, CobiT, GAISP,
NIST, ...), u sluĉaju parniĉnog spora zbog zloupotrebe IKT i/ili
kompjuterskog kriminala.

Standard ISO/IEC 17799 preporučuje ukljuĉivanje sledećih elemenata u

politiku zaštite na nivou organizacije:

- uvod, u kojem se potvrĊuje odluĉnost i podrška menadţmenta

organizacije zaštiti informacija,
- organizaciona pitanja, koja sadrţe opis svih delova politike,
komisije, radne timove, kontaktne informacije i.t.d. angaţovane u
oblasti zaštite informacija,

- 362 -
- bezbednosna klasifikacija i kategorizacija, koja opisuje objekte
IKT sistema, njihove vrednosti i znaĉaj i neophodne nivoe
zaštite,
- sistematizaciju radnih mesta, koja karakteriše mere personalne
zaštite kao što su opis duţnosti sa aspekta zaštite informacija i
organizacija obuke personala,
- fizička zaštita objekata,
- upravljanje raĉunarima i raĉunarskim sistemima,
- pravila pristupa objektima IKT sistema,
- redosled razvoja i implementacije sistema zaštite,
- mere za obezbeĎenje kontinuiteta poslovanja i upravljanja
vanrednim dogaĊajem i
- normativni deo, koji potvrĊuje usaglašenost politike zaštite sa
postojećim zakonima.

- 363 -
1.4. Opšti model za izradu politike zaštite

Opšti funkcionalni model politike zaštite u odnosu na sve aspekte

zaštite u IKT, koji povezuje sve elemente sistema zaštite, prikazan je na
Sl.1.1, [9]:

Zaposleni moraju politiku zaštite uzeti veoma ozbiljno, a svaki pojedinac

prihvatiti odgovornost. Politika zaštite treba da obezbeĊuje osnov za
disciplinske mere, ukljuĉujući udaljavanje sa posla i zakonsko gonjenje.

Svest o potrebi zaštite, obuka, obrazovanje

NIR, Analiza
Arhitektura, osetljivosti IS,
Upravljanje
Projektovanje i Detekcija
incidentom,
razvoj, malicioznih
Reinţenjering,
Evaluacija, programa,
Re-sertifikacija i
Politika zaštite

Testiranje, Detekcija upada

Re-akreditacija
Sertifikacijai i (IDS),
akreditacija Nadzor i kontrola

Akvizicija Operativni rad Odrţavanje

Zaštite Detekcija Korekcija

Poverljivost Integritet Raspoloţivost

Tehnologija Procedure Bezb. pouzdanost
(Assurance)
Analiza i procena rizika

Analiza i procena pretnji

Sl.1.1. Model politike zaštite

- 364 -
1.5. Preporuke za izradu politike zaštite

Osnovna komponenta programa zaštite je politika zaštite, koja

odraţava pristup organizacije zaštiti svojih informacija, a izraĊuje se na
osnovu analize rizika. Da bi se izradila politika zaštite treba izvršiti
bezbednosnu klasifikaciju i kategorizaciju objekata IKT sistema i
mapirati ih na bazi objektno orijentisanog pristupa, [9].

Sa praktiĉnog stanovišta svrsishodno je politiku zaštite posmatrati na tri

osnovna nivoa: organizacije, IKT sistema i sistema (komponente) zaštite.
MeĊutim, pogrešno je oĉekivati da će svi korisnici sprovoditi usvojenu
politiku zaštite, ĉak i posle adekvatne obuke. Brzina sa kojom se menjaju
faktori rizika, zahteva kontinualan pristup politici zaštite, koji se najbolje
opisuje procesom ―ispituj i popravljaj‖. Ovo implicira neprekidnost
nadzora i kontrole sistema zaštite, ispitivanja ranjivosti sistema i
okruţenja, bezbednosnih popravki (zakrpa) i odbrane kroz upravljaĉke
funkcije zaštite, poboljšanje kontrola zaštite ili izmenu politike zaštite
(Sl. 1.2), [8].

3. AKTIVNI
NADZOR
SISTEMA
ZAŠTITE

2. PROJEKTOVANJE
1. IZDAVANJE 4. TESTIRANJE
SISTEMA
POLITIKE IS NA UPAD
ZAŠTITE
ZAŠTITE

5. UPRAVLJAQNJE
SISTEMOM ZAŠTITE

Sl. 1.2. Neprekidnost procesa odrţavanja politike zaštite

Dobra politika zaštite treba da:

- obezbedi podršku upravne strukture;

- bude laka za razumevanje i što je moguće kraća;
- bude usklaĊena sa kulturom, radnim funkcijama i okruţenjem;
- bude racionalna i da omogućava organizaciji postizanje
poslovnih ciljeva;
- bude obavezna i da nameće realizaciju;
- afirmativno istiĉe ono što treba uraditi (treba, mora, hoće,..), a
izbegava reĉi tipa nikada, zabranjeno i sl.;

- 365 -
- se odnosi na sve tipove i klase informacija, opreme i mreţa;
- se uklapa u druge politike organizacije;
- sadrţi saopštenja šta treba zaštititi i u kom obimu;
- sadrţi informaciju kada politika stupa na snagu;
- sadrţi informaciju na koga se politika primenjuje (odnosi);
- sadrţi razloge za propisivanje politike i ko je razvio politiku;
- sadrţi metod kojim će se monitorisati usklaĊenost propisane
politika i prakse;
- objašnjava kako će politika biti nametnuta, ko je odgovoran za
nametanje i akcije koje se preduzimaju u sluĉaju neusaglašavanja
prakse sa politikom;
- objašnjava koja su odstupanja od utvrĊene politike dopuštena,
ako ih ima;
- sadrţi informaciju kada će se politika preispitivati i koji autoritet
vrši reviziju;
- sadrţi datum poslednje revizije i da li postoji arhiva politika;
- sadrţi termin elektronski za informacije u elektronskoj formi, a
ne koristi taj termin za opšte informacije, bez obzira na
tehnologiju i medije;
- identifikuje kontaktne informacije za izveštavanje o incidentu,
sumnjivom ponašanju, anomalijama i indikatorima incidenta;
- uravnoteţi nivo kontrola zaštite i nivo efektivnosti;
- bude prilagoĊena veliĉini organizacije i
- obezbedi poverenje korisnika u kljuĉne komponente zaštite.

- 366 -
2. IZRADA POLITIKE ZAŠTITE

2.1. Osnovni atributi politike i procedure zaštite

Osnovni atributi politike zaštite mogu se definisati na brojne

naĉine, a prihvatljiv skup je: sadržaj, potreba, namena, pristup u praksi i
pogodnost za primenu u specifiĉnoj situaciji.

Oblast zaštite je u celini kompleksna i teško dostiţna. Bilo koja

prihvatljivo kompletna analiza daje obilje razliĉitih detalja. Odgovarajuća
politika moţe se odnositi na one aspekte zaštite za koje menadţment
smatra da treba da budu tretirani. U suštini, politika zaštite tvrdi, u opštoj
formi, šta je dopušteno, a šta nije dopušteno u oblasti zaštite u toku rada
konkretnog sistema. Politika zaštite obiĉno nije sasvim specifiĉna; ona
sugeriše šta je od najvećeg znaĉaja i šta treba uraditi, a ne kako treba
postići ţeljene rezultate.

Pošto je politika zaštite tako uopštena nije jasno spolja kako se moţe
povezati sa datom aplikacijom. Ĉesto je najbolji naĉin da se ovo
postigne, da se politika zaštite podvrgne procesu sukcesivnog
usavršavanja i dogradnje dodavanjem više detalja za svaku aplikaciju u
svakoj fazi. Za to je potrebno poznavati domen aplikacije u svetlu
generalne politike.

- 367 -
2.2. Osnovni kriterijumi za izradu politike zaštite

U skladu sa standardom zaštite ISO/IEC 17799, organizacije treba da

imaju najmanje tri sledeća tipa politika zaštite:

- Program (Programsku politiku na nivou organizacije, ili

Direktivu),
- Politiku na nivou IKT sistem i
- Politiku na nivou funkcionalnih komponenti ili sistema zaštite.

Sva tri tipa politika zaštite treba da se generišu na bazi sledećih

kriterijuma, [3]:
Dopunjavanja: organizacija treba da razvije komplementarna dokumenta
zaštite - interne standarde, uputstva i procedure koje obezbeĊuju
korisnicima, menadţerima i drugima u zaštiti metod za implementaciju
politika i ispunjavanje ciljeva zaštite organizacije.
Vidljivost (transparentnost): pomaţe implementaciju politike na taj
naĉin što obezbeĊuje prenošenje politika u celini svim zaposlenim u
organizaciji.
Menadžerska podrška: bez podrške menadţmenta, politika postaje samo
prazan indikator angaţovanosti menadţmenta u zaštiti.
Konzistentnost: treba razmotriti sve druge direktive, zakone, standarde,
principe zaštite, kulturu organizacije, uputstva i procedure i uskladiti sa
misijom organizacije.
Eksplicitnost saopštenja: izjave (saopštenja) politike zaštite treba da
opisuju vrlo opštim, uobiĉajenim i jednostavnim (razumljivim) izrazima
kako neka organizacija bira naĉin rešavanja bezbednosnih pitanja. Izjave
politike zaštite treba da razdvajaju i eksplicitno istiĉu atribute:
prihvatljivosti (šta je dopušteno), neprihvatljivosti (šta nije dopušteno) i
neadekvatnosti (šta ne odgovara). Prihvatljivo je svako ponašanje ili
dogaĊaj u sistemu koji nije eksplicitno naveden da je neprihvatljiv ili
neodgovarajući. Neprihvatljiva su stanja ili postupci koje organizacija ne
moţe tolerisati. Neodgovarajuće su situacije ili ponašanja koja su
neţeljena, ali se moţe pokazati da su neizbeţna. Izjave koje oznaĉavaju
neprihvatljivo ponašanje, znaĉe obavezno izvršavanje (mora-»must«), a
izjave koje su namenjene za spreĉavanje neprihvatljivog
ponašanja/dogaĊanja, moraju (treba - »should«) se ispuniti u najboljoj
mogućoj meri. Ova jednostavna konvencija uvodi ograniĉenu
fleksibilnost u politiku zaštite, koja omogućava velikim organizacijama
da fino doteruju ove politike.

- 368 -
2.3. Izraţavanje znaĉaja politika zaštite

U izradi svake politike zaštite treba nedvosmisleno izraziti nominalni

generiĉki znaĉaj politike zaštite. Generalno, značaj politika zaštite je
višestruk, [9]:

- obezbeĊuju uputstva,
- formiraju osnovu za kontrolni okvir upravljanja zaštitom,
- definišu uloge i odgovornosti u zaštiti i
- dokumentuju stav organizacije u odnosu na odreĊeno pitanje
zaštite.

Funkcija uputstva odnosi se na to kako se odreĊene aktivnosti trebaju ili

ne trebaju izvršiti. Razmatraju se brojna pitanja – poznati rizici, legalni i
regulatorni zahtevi, kulturne vrednosti.

Politike zaštite su nedvosmislene i razumljive za kontrolni okvir.

Kontrolni okvir ĉine saopštenja politika zaštite, standardi, procedure,
radna dokumenta i tehniĉke mere implementirane za obezbeĊenje dnevno
operativnog rada sistema. Pretpostavlja se stabilnost kontrolnog okvira u
nekom vremenu. Kontrolni okvir je priznavanje ĉinjenice da ne moţemo
analizirati posledice rutinskih akcija svaki put kada se one preduzmu.
Kontrolni okvir obezbeĊuje rešenje ovog problema standardizacijom
naĉina na koji se akcija izvršava na bazi inicijalne analize. Kako procesi
zaštite organizacije postaju zreliji to se očekuje da se kontrolni okvir
upravljan politikom zaštite pomera i zameni sa procenom rizika, što
ukazuje na sposobnost organizacije da brzo reaguje na sve promene u
okruženju. Tehnike analize rizika koriste se za merenje rizika u datom
vremenskom trenutku. Analiza rizika treba da bude ulaz u proces
dizajniranja politike i moţe se koristiti svaki put za proveru adekvatnosti
politike u posebnim okolnostima, [14].

Saopštenja politike zaštite posebno su efikasan metod za definisanje

uloga i odgovornosti u datoj oblasti zaštite i ĉesto se koriste za ovu
namenu. Korišćenje uloga i odgovornosti ima posebnu prednost, jer
koncept ne zavisi od organizacione strukture, što omogućava da se uloge
mapiraju sa upravljaĉkim pozicijama na fleksibilan naĉin (posebno
korisno kada se vrši reorganizacija). Ovde je kritiĉno da se preklapanja i
meĊuzavisnosti izjava politika korektno kontrolišu i da su proistekle
uloge i odgovornosti koherentno povezane.

- 369 -
Politike zaštite dokumentuju i naĉine rešavanja posebnih pitanja, na
osnovu brojnih zahteva.

2.4. Identifikovanje i definisanje saopštenja politike zaštite

U domenu zaštite informacija nema ĉvrstih i brzo primenljivih

pravila za definisanje obima i sadrţaja politika zaštite. Uzorci izjava
brojnih politika zaštite na raspolaganju su na Internetu za širok krug
pitanja (SANS Institut, NIST i brojne druge institucije). Ova saopštenja
politika zaštite velika su pomoć svakom profesionalcu u zaštiti, ali do
konkretnih politika zaštite nije lako doći, jer su poverljivi autorski radovi.
Dobar metodološki postupak za izradu saopštenja konkretne politike
zaštite obezbeĊen je definisanjem standardne strukture zajedniĉkih i
specifiĉnih elemenata politika zaštite. Brojni uzorci saopštenja politika
zaštite mogu se naći u literaturi, [4], [10], [12], [15].

Definisanje strukture politike zaštite bitno je za standardizovanu izradu i

implementaciju politika zaštite, koje zavise od kulture rada i veliĉine
organizacije. Jednostavnija politika zaštite odgovara manjim
organizacijama, a za veće su potrebna mnogo preciznija saopštenja
politika zaštite sa više restrikcija. Generalno, bolje je imati više politika
zaštite na različitim nivoima nego jednu usmerenu i kratku, ali je teško
izbeći preklapanja i ponavljanja. TakoĊe, jedinstvena politika zaštite za
veliku organizaciju moţe biti neprihvatljivo velik dokument. Zato je
kljuĉno pitanje kako struktuirati dokument politike zaštite. Sve pomenute
vrste politika zaštite treba da imaju jedinstvenu sledeću opštu strukturu,
[14]:

Tipiĉna opšta struktura politike zaštite

Naslov
Autor
Verzija
Datum
Amandmani (... kontrolni podaci dokumenta)
Namena: ciljna grupa za koju je dokument namenjen.

- 370 -
 1. Uvod: kratak uvod u izjave politike zaštite sa objašnjenjem
konteksta sistema zaštite.
2. Struktura i obim: opis obima politike i pregled strukture
dokumenta.
3. Bezbednosni cilj: navesti sve bezbednosne ciljeve po
pretpostavljenim prioritetima...
4. (specifični elementi koji se odnose na posebnu politiku zaštite i
na razliĉitim nivoima).
....
n. Reĉnik termina: kljuĉne reĉi korišćene u dokumentu.
n+1. Odobrava: poslednja stranica koja se dodaje, a koju potpisuje
akreditacioni autoritet.

Struktura konkretnog dokumenata politika zaštite na razliĉitim nivoima i

za razliĉite komponente zaštite, razlikuju se meĊusobno od 3. taĉke (4. –
n).

2.4.1. Identifikovanje strukture Programa zaštite

Namena programa (Programske politike zaštite) neke organizacije

je da:
Kreira i definiše Program zaštite IKT sistema: programska politika treba
da jasno i eksplicitno navede koje resurse, ukljuĉujući hardverske,
softverske, informacione i personalne, program zaštite treba da pokriva.
Postavi strategijske pravce zaštite: ovo moţe ukljuĉiti definisanje ciljeva
programa. Na primer, u nekom sistemu za odrţavanja velike baze
podataka kritiĉne za misiju organizacije specifiĉno mogu biti naglašeni
ciljevi redukcije grešaka, zaštite od gubitaka informacija, korupcije
podataka i razvoja kapaciteta za oporavak sistema.
Definiše odgovornosti: koje treba pripisati licima za direktnu
implementaciju programa i druge odgovornosti odgovarajućim
menadţerima.
Obuhvati pitanja usaglašenosti tipiĉno dva tipa:

1) Opšte - ispunjavanje zahteva normativa za uspostavljanje

programa i odgovornosti u različitim komponentama organizacije
i
2) Specifične - korišćenje specifičnih sankcija i disciplinskih mera i
akcija za neusklaĎenost.

- 371 -
Struktura Programske politike zaštite:

1– 3. (Tipiĉni deo opšte strukture politike zaštite).

4. Izjava upravne strukture: saopštenje o angaţovanju izvršnih
menadţera u zaštiti.
5. Opšte odgovornosti: najvaţnije odgovornosti za sve zaposlene u
organizaciji i spoljne provajdere usluga poreĊane po bulitima.
6. Odgovornosti menadžmenta: zbirna odgovornost upravne strukture
(najvaţnija - da obezbede da svi zaposleni budu svesni potrebe ove
politike zaštite).
7. Odgovornost TTPS: zbirna odgovornost koja se primenjuje na spoljne
saradnike.
8. Druga dokumenta: objašnjava hijerarhiju odnosnih dokumenata
zaštite i znaĉaj standarda i uputstava.
9. Kontakti: lista vaţnih kontakata, gde se referenciraju funkcije, a ne
imena.
10. Politika autorskog prava: opis zahteva za dobrovoljno ustupanje
autorskih prava na ovaj dokument.

2.4.2. Politika zaštite na nivou IKT sistema

Politika zaštite na nivou IKT sistema (System-Specific Policy)

treba da:
Istakne odluke: eksplicitno navesti odluke koje je upravna struktura
donela za zaštitu sistema, definisati meru u kojoj će se pojedinci smatrati
odgovornim za akcije u sistemu.
Bude odobrena: odluke koje uprava donosi treba da su zasnovane na
tehniĉkoj analizi sistema (rizika, pretnji, ranjivosti), koja je osnova za
odobravanje (akreditaciju) politike.
Bude fleksibilna: da varira od sistema do sistema zavisno od
bezbednosnih ciljeva, baziranih na operativnim zahtevima, okruţenju,
menadţerskom prihvatanju rizika i razliĉitim potrebama za detaljima u
politici zaštite.
Bude saopštena kao pravila: ovlašćenja ko (prema poloţaju, kategoriji
posla ili imenu) i šta ko moţe uraditi (modifikovati, brisati, ĉitati,...) na
specifiĉnim klasama objekata IKT sistema i pod kojim uslovima.

- 372 -
Struktura Politike zaštite na nivou IKT sistema:

1. – 3. (Tipiĉni deo opšte strukture politike zaštite)

4. Uloge i odgovornosti: detaljne uloge i odgovornosti za bezbednost
IKT sistema.
5. Fizička zaštita IKT sistema: saopštenje o fiziĉkoj zaštiti objekata
sistema, raĉunarske i serverske sobe, eventualnoj integraciji fiziĉke i
logiĉke kontrole pristupa.
6. Upotreba kriptografije: saopštenje se odnosi na korišćenje
mehanizama kriptozaštite, specijalne opreme, algoritama i protokola.
7. Autentifikacija: zahtevi za autentifikaciju, za razliĉite kontekste –
interne konekcije, udaljeni pristup, kontrole mreţnog pristupa, Internet
veze i dr.
8. Autorizacija i kontrola pristupa: saopštenje se odnosi na uputstvo
kako se vrši autorizacija (kriterijumi, model) i logiĉka kontrola pristupa
objektima sistema.
9. Zaštita poverljivosti: saopštenje navodi koji objekti informacija i
podataka na radnim stanicama, serverima i mreţi sistema zahtevaju
zaštitu poverljivosti.
10. Zaštita integriteta: saopštenje navodi koji objekti informacija i
podataka na radnim stanicama, serverima i mreţi sistema zahtevaju
zaštitu integriteta.
11. Zaštita raspoloživosti: saopštenje navodi koji objekti informacija i
podataka na radnim stanicama, serverima i mreţi sistema zahtevaju
zaštitu raspoloţivosti.
12. Logovanje i kontrolni tragovi: saopštenje navodi obavezu
dokumentovanja i upravljanja konfiguracijom sistema, naĉin i obavezu
monitorisanja sistema log datoteka.
13. Upravljanje kompjuterskim incidentom: saopštenje navodi kako
detektovati napad i upravljati incidentima i alarmima sa opisom
ozbiljnosti i verovatnoće pojave incidenta i reakcijom na incident.
14. Druga razmatranja: kako politiku treba interpretirati

Napomena:
Zavisno od IKT sistema i zahteva organizacije mogu se obuhvatiti i
druge komponente programa zaštite, na primer: personalna zaštita,
sertifikacija i akreditacija i dr.

- 373 -
Struktura Politike zaštite privatnosti:

1. – 3. (Tipiĉni deo opšte strukture politike zaštite)

4. Uskladištene informacije: kratak opis tipa informacija uskladištenih u
IKT sistemu sa opisom razloga zbog kojih su ove informacije
uskladištene.
5. Metod skupljanja informacija: lista metoda koji se koriste za
skupljanje informacija o klijentima i ostalim trećim stranama.
6. Upravljanje kolaĉićima: iako se kolaĉići koriste za skupljanje
informacija, sekcija je posvećena korišćenju kolaĉića da bi se obezbedila
dobra informisanost korisnika web lokacije.
7. Pristup liĉnim podacima: u ovoj sekciji identifikuje se ko ima pristup
personalnim informacijama i zašto, kao i kako se taj pristup odnosi
prema tekućim zahtevima.
8. Aţuriranje liĉnih podataka: obuhvata proceduru za aţuriranje ili
modifikaciju uskladištenih podataka, koju moţe podrţavati zaštićena
veza koja omogućava korisnicima da sami aţuriraju svoje liĉne podatke.
9. Zahtev za iskljuĉivanje: informacija o tome kako se podnosi zahtev
za uklanjanje liĉnih podataka korisnika iz IKT sistema.
10. Dostupnost za treću stranu: opisuje koja treća strana ima pristup
liĉnim podacima i pod kojim uslovima (policija, pravosudni organi i sl.).
11. Ostale informacije: date su kontaktne informacije za informisanje o
ostalim pitanjima.

2.4.3. Politika zaštite funkcionalnih komponenti

Politika zaštite funkcionalnih komponenti (Issue-Specific Policy)

moţe da si izradi u sastavu neke od kljuĉnih, standardnih politika zaštite
ili kao samostalni dokument, u kojem sluĉaju politika zaštite
funkcionalnih komponenti treba da sadrţi Tipični opšti deo strukture
politike zaštite (1. – 3.), kao i da:

Obuhvati specifične oblasti: prioritetne bezbednosne zahteve i relevantne

objekte za zaštitu. Na primer, Politiku zaštite privatnosti e-mail poruka
ili Politiku povezivanja na Internet.
Bude često ažurirana: ĉeste modifikacije zahtevaju se u skladu sa
tehnološkim i drugim promenama. Na primer, politika zaštite za
korišćenje poslednje tehnologije zaštite sa još uvek nepoznatim
ranjivostima, zahteva redovno aţuriranje bezbednosnih popravki.

- 374 -
Sadrži saopštenje o obuhvaćenom pitanju: eksplicitno navedeni stav
organizacije prema specifiĉnom pitanju zaštite, primenljivost, uloge i
odgovornosti, usaglašenost i kontaktne informacije.

U radnom dokumentu, Tabela 1. PRILOG II 7A, navedeni su glavni

elementi specifiĉnih saopštenja osnovnih politika zaštite funkcionalnih
komponenti, koji se mogu koristiti u formulisanju i izradi politika zaštite
u konkretnoj organizaciji, kao pomoćni dokument za usmeravanje
specijalista zaštite. Primeri formulisanih saopštenja politika zaštite dati
su u PRILOGU II 7B. U PRILOGU II 7C data je nešto drugaĉija
forma saopštenja politike zaštite organizacije REsecure (Informations
Security Polices), [15], u kojoj se eksplicitno isteĉe veza sa relevantnim
standardom zaštite koji podrţava konkretnu politiku. U PRILOGU II 7D
dati su primeri politika funkcionalnih komponenti zaštite (SANS
Institute), [7].

Da bi se praktiĉno primenila sva navedena uputstva za izradu politike

zaštite, razvijena je Vežba GII P7A u kojoj studenti u grupnom radu
imaju zadatak da primene sve raspoloţive instrukcije, modele i uzorke i
izrade odreĊeni tip politike zaštite za konkretne ulazne podatke iz realnog
(anonimnog) sistema. Vežba GII P7B, sa radnim primerom i
ilustrovanim procesom filtriranja paketa, namenjena za projektovanje i
izradu politike zaštite za barijere (firewall) sa filtriranjem paketa,
razvijena je sa ciljem da studenti kroz praktiĉnu obuku shvate koliki je
nivo specijalistiĉkih znanja potreban za razvoj politike zaštite specifiĉne
komponente sistema zaštite.

U razvoju dokumenta Politika zaštite na osnovu uzoraka i uputstava

raspoloţivih u bazama znanja, ĉesto se ĉitaoci zbunjuju u identifikovanju
saopštenja (izjava) i prepoznavanju pripadajuće politike zaštite u kojoj se
ta izjava ili druga karakteristika moraju naći. Vežba GII P7C namenjena
je da smanji teţinu ovog praktiĉnog problema.

Infrastrukturna i bezbednosna komponenta savremenih poslovnih IS –

infrastruktura sa javnim ključem (PKI), od posebnog je znaĉaja za
razvoj sistema e-uprave, e-trgovine i uopšte e-poslovanja, jer obezbeĊuje
niz neophodnih funkcionalnosti, zaštitu IS (integriteta, poverljivosti i
raspoloţivosti informacija, jaku autentifikaciju i neporecivost) i, što je još
vaţnije, uzajamno poverenje svih uĉesnika u e-transakcijama. Naţalost, u
bazama znanja nema dovoljno kvalitetnih uzoraka politika zaštite za PKI

- 375 -
sistem. U Vežbi GII 7D razvijeno je uputstvo za izradu politike zaštite
PKI sistema, sa ciljem da ga studenti u okviru veţbe koriste za
samostalnu izradu izabranog tipa politike PKI sistema za konkretni
(anonimni) IS.

- 376 -
2.5. Razvoj procedura zaštite

Procedure zaštite spuštaju politiku zaštite na operativni nivo i

objašnjavaju praktiĉne korake kako se implementira politika zaštite u
dnevnom radu. UsklaĊenost prakse i politike zaštite u velikoj meri zavisi
od toga koliko su kompletne procedure zaštite i koliko dobro definišu i
opisuju zadatke koje treba izvršiti da bi se ispunili bezbednosni zahtevi
politike zaštite.

Na primer: Funkcionalna politika zaštite u zdravstvenom IS koja se

odnosi na zaštitu zdravstvenih i liĉnih podataka kroz procedure zaštite
moţe:

- identifikovati osoblje koje ima pristup diagnostiĉkim izveštajima,

- specificirati proces autentifikacije i autorizacije zahteva,
- definisati tip fiziĉke zaštite (n.p.r. ne ostavljati izveštaj na stolu),
- definisati naĉin unošenja dijagnostiĉkih informacija,
- definisati kriptološki algoritam kojeg treba koristiti,
- identifikovati lica kojima se prenose informacije,
- sugerisati kako se izbegavaju uobiĉajene greške i.t.d.

Sa aspekta procesnog pristupa zaštiti procedura predstavlja kohezioni

faktor procesa zaštite. Naime, procesi zaštite se mogu dekomponovati u
tri kljuĉna skupa aktivnosti:

- za upravljanje procesom, koje koordiniraju jedinstven i

koherentan rad svih delova celine procesa,
- proceduru procesa ili skup funkcionalnih aktivnosti za
izvršavanje procesa sa redosledom i prioritetom izvršavanja
aktivnosti i njihovim meĊusobnim vezama i
- skup aktivnosti za dokumentovanje kontrola i izlaza projekta (v.
G II, p. 3).

Uobiĉajeno je da se procesi zaštite normalno dokumentuju kroz sastavne

procedure koje se zatim što detaljnije opisuju u dokumentaciji zaštite,
dajući odgovore KAKO se izvršavaju konkretne aktivnosti u procesima
zaštite. Pri tome, ĉesto treba koristiti zdravu logiku, apriorna i opšta
znanja i opšte principe elementarne logike (analizu, sintezu, apstrakciju,
dedukciju i dr.) da se smanji kompleksnost, izbegne nepotrebno
ponavljanje i odredi racionalan nivo detalja u svakoj proceduri i

- 377 -
dokumentu zaštite. Na taj naĉin pojednostavljuje se proces odrţavanja
sistema zaštite i povećava verovatnoća da će procedure i dokumenta
zaštite biti stvarno korišćeni.

Opis procesa zaštite kroz detaljne procedure specificira redosled

izvršavanja aktivnosti i kako se one izvršavaju u konkretnom procesu, a
generiše se u dokumentu Procedure zaštite na razliĉitim nivoima (na
primer, Procedura za administratora zaštite za dodeljivanje prava
pristupa).

Procedure zaštite generalno mogu da se izraĊuju za sve procese:

upravljaĉke, organizaciono-operativne i tehniĉke. U praksi zaštite,
uobiĉajeno je da su tehniĉke procedure sastavni deo tehniĉke
dokumentacije i namenjene su za operatere ureĊaja i administratore.
Obiĉno ih izraĊuju snabdevaĉi IKT proizvoda zaštite (Primer: procedura
podešavanje bezbednosnih mehanizama u OS Windows XP izraĊena je u
posebnoj instrukciji [2]). Uobiĉajeno, u praksi zaštite termin Procedura
zaštite odnosi sa na upravljaĉke i organizaciono-operativne komponente
programa zaštite, koje se ĉesto nazivaju proceduralne komponente
zaštite.

Nekoliko primera uzoraka procedura zaštite dato je u PRILOGU II 7E,

[11], [7].

- 378 -
2.6. Implementacija politike, standarda, uputstava i procedura
zaštite

Treba razviti detaljan Plan zaštite za implementaciju politike,

standarda, uputstava i procedura, kada dokumenta zaštite prihvati uprava
organizacije. MeĊu kljuĉnim faktorima uspeha implementacije su:

- potpuna podrška upravne strukture;

- efikasan prenos ciljeva dokumenta zaštite svim zaposlenim;
- prepoznavanje jedinstvenih kulturoloških, etiĉkih i drugih
zahteva organizacije;
- ukljuĉivanje kompetentnih i struĉnih timova organizacije;
- imenovanje odgovornog tima ili pojedinaca za sve ove poslove;
- definisanje i ugradnja mehanizama za detekciju, korekciju i do-
obuku i ponovnu edukaciju u sluĉaju proboja.

Radni dokument Kontrolna lista procesa implementacije politike i

procedura zaštite dat je u PRILOGU II 7F. Uzorci Uputstava zaštite
prikazani su u PRILOGU II 7 G.

- 379 -
3. REZIME

Politike, standardi, uputstava i procedure zaštite mehanizmi su

pomoću kojih upravna struktura izraţava i podrţava svoje stavove u
odnosu na problematiku zaštite objekata IKT sistema i sva pitanja koja se
na nju odnose. Politika zaštite je formalni izraz uverenja upravne
strukture da su podaci i informacije i drugi objekti dragocena imovina
organizacije, koja se mora tretirati i štititi kao i sva druga vredna
imovina organizacije. Politika zaštite treba da se prezentira zaposlenima
u istom formatu i kroz iste kanale u organizaciji kao i druge politike
organizacije (poslovna i dr.), kroz iste distribucione liste, uputstva i sl.
Politika, standardi, uputstava i procedure zaštite moraju biti realni u
pogledu uticaja okruţenja, etiĉkih i kulturoloških principa organizacije;
moraju biti predstavljeni i nametnuti na takav naĉin da zaposleni na svim
nivoima shvate da je upravna struktura veoma ozbiljna u pogledu
njihovog znaĉaja, implementacije i prakse.

Aktivna podrška upravne strukture izuzetno je kritiĉna za uspešnu

implementaciju programa i politike zaštite. Standardi i uputstva
obezbeĊuju znaĉajnu podršku za implementaciju politika i procedura
zaštite i neophodni su da odobrena politika i procedure zaštite postanu
efikasni i efektivni. Procedure propisuju specifiĉne postupke za stvarnu
implementaciju politike zaštite formirane na bazi standarda i uputstava
koji je podrţavaju. One su ĉesto sasvim detaljne da bi osigurale efikasnu
implementaciju i minimizirale nerazumevanja i greške.

Program za obuku i razvoj svesti o potrebi zaštite za menadţment i druge

zaposlene treba prilagoditi tako da predstavlja mehanizam za prenos
informacija o usvajanju politike i odgovarajućih standarda, uputstava i
procedura zaštite svim zaposlenim i da oni potpuno shvate svoju
kolektivnu i pojedinaĉnu ulogu i odgovornost u procesu zaštite. Drugi
vaţan elemenat je da zaposleni shvate zašto su podaci i informacije
vredna imovina organizacije i zašto se moraju štititi.

Dok se standardna struktura politike zaštite relativno sporo menja,

sadrţaj politika, a posebno procedura zaštite treba da aţurno prati razvoj
otvorenih (OSI referentnog modela), visoko distribuiranih IKT sistema,
sistema i komponenti zaštite. Potrebne su brojne politike (saopštenja) i
procedure zaštite za sisteme kontrola pristupa, metodologije bekapovanja
i razliĉitih mera fiziĉke zaštite, projektovanih za ovakvo okruţenje,

- 380 -
posebno ako IKT sistem ukljuĉuje mreţu, raĉunare, magnetske medije
i.t.d., koji ĉesto nisu pod kontrolom centralnog entiteta za upravljanje
sistemom zaštite. Politika zaštite treba da obaveţe organizaciju na
centralizovano upravljanje sistemom zaštite, koje omogućava centralnu
administraciju servisa i drugih funkcija zaštite, efikasniji i ĉešći nadzor i
kontrolu usaglašenosti prakse i politike zaštite, za što su korisni i efikasni
i neki aplikativni programski proizvodi.

Implementaciju politike i procedura zaštite treba paţljivo planirati

detaljnim dokumentom Plan sistema zaštite, da bi se obezbedila
maksimalna efikasnost, sa minimalnim odstupanjem radnih procesa i
funkcija.

- 381 -
4. KLJUĈNI TERMINI

Politika zaštite: kljuĉni dokument programa zaštite, formiran na bazi

standarda i uputstava koji je podrţavaju; sadrţi bezbednosne ciljeve
organizacije u odnosu na odreĊenu oblast/komponentu sistema zaštite
kroz skup izjava o tome ŠTA treba raditi u oblasti zaštite i skup pravila
za pristup i bezbedno korišćenje informacija i IKT sistema.
Procedura zaštite: sadrţi detalje o tome KAKO nešto treba uraditi iz
politike zaštite; definiše i opisuje zadatke koje treba izvršiti da bi se
ispunili bezbednosni zahtevi politike zaštite; propisuje specifiĉne
postupke (redosled i prioritet) za konkretnu implementaciju politike
zaštite,.
Struktura politike zaštite: standardizovana metodološka forma
izlaganja sadrţaja dokumenta politike zaštite, koja obuhvata jedinstven
opšti deo za sve tipove politika zaštite i specifiĉni deo za odreĊenu
politiku zaštite, koji zavisi od nivoa politike zaštite i vrste funkcionalne
komponente na koji se politika odnosi.
Saopštenje politike zaštite: eksplicitna izjava koju politika zaštite sadrţi
o odreĊenim pitanjima zaštite; daje se u razumljivoj formi, sa jasnim i
jednostavnim terminima; eksplicitno navedeni stav organizacije prema
specifiĉnom pitanju zaštite, izraţava primenljivost, uloge i odgovornosti,
usaglašenost i kontaktne informacije.

- 382 -
5. LITERATURA

1. American Bar Association, Section of Science &Technology

Law, Privacy & Computer Crime Committee, International
Strategy for Cyberspace Security,
www.abanet.org/abapubs/books/cybercrime, 2003.
2. Anthony Harris, Murugiah Souppaya, Paul M. Johnson, Karen
Kent, Guidance for Securing Microsoft Windows XP Systems for
IT Professionals: A NIST Security Configuration Checklist, NIST
SP 68,
http://www. csrc.nist.gov/publications.
3. Domarev V.V.,Защита информации и безопасность
компьютерных систем, 1997.
4. FIPS pubs, http://www.itl.nist.gov/fipspubs, 2003.
5. Gary Smith: A brief Taxonomy of Firewalls-great Walls of Fire,
SANS Institute, http://www.sans.org/rr/firewall/taxonomy.php,
18 maj 2001.
6. Harold F. Tipton, Micki Krause: The information security
handbook, 4th izdanje vol.2.CRC Press LLC, 2001.
html://www.oecd_1997_guidlines_ policyKz, Paris, 1997.
7. http://www.sans.org/policies, Information Security Policy & Best
Practices, SANS Institute, 2003.
8. IT Governance Institute, COBIT (Control Objectives for
rd
Information and related Technology) 3 Edition, 2000,
www.ITgovernance.org, www.isaca.org.
9. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
10. NIST SP 800-12, An introduction to computer Security - The
NIST Handbook, http://www.csrc.nist.gov/publications,
1997/2003. http://www.nist.gov/publications,
11. NIST SP 800-18, Guide for developing Security Plans for IT
Systems, 1998.
12. NSA (National Security Agency), Security Recommendation
Guide, http://www.nsa.gov/snac/index.html, septembar,2003.
13. OECD, The Cryptography Policy: Guidelines and the Issues,
14. Purser S., A practical guide to managing information security,
Artech House, Boston, London, http://www.artechhouse.com,
2005.

- 383 -
15. RealSecure, http://www.realsecure.org/security/policies, 2003.
16. RFC 2196, Site Security handbook,
http://www.icann.rfceditor.org, 1997.

- 384 -
8. IMPLEMENTACIJA I INTEGRACIJA PROGRAMA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja razumećete:

- opštu metodologiju za implementaciju programa zaštite
- tok procesa implementacije programa/sistema zaštite
- ključne komponente procesa implementacije:
obuku zaposlenih
kontrolu usklaĎenosti
nametanje obaveze izvršavanja

Glavni cilj svakog programa zaštite je da obezbedi efikasno

upravljanje rizikom koji prati svaku tehnologiju pa i IKT. Upravljanje
rizikom ukljuĉuje upravljanje sa povredama privatnosti, incidentima u
sistemu zaštite, neovlašćenim aktivnostima, malicioznim napadima i.t.d.
Program zaštite treba da bude osnov na kojem se vode poslovi
organizacije i mora biti u celini implementiran. Odnosno, rizik nije
moguće redukovati ako se plan zaštite ne implementira. Program zaštite
moraju realizovati zaposleni u organizaciji, a odgovornost za to imaju svi
menadţeri na svim nivoima u organizaciji. Glavni menadţer organizacije
mora imenovati odgovarajuća lica za koordinaciju i nadgledanje procesa
realizacije programa zaštite. Ova lica moraju biti sposobna da
identifikuju interne i eksterne faktore rizika za poverljivost, integritet i
raspoloţivost podataka i informacija, ukljuĉujući i rizik od nedovoljne i
nekvalitetne obuke u oblastima: upravljanja zaštitom; bezbednog
procesiranja, skladištenja, prenosa, ili odlaganja liĉnih informacija u IKT
sistemu; upravljanja kompjuterskim incidentom; godišnjeg izveštavanja o
reviziji programa sa aspekta efikasnosti i usklaĊenosti i upravljanja
promenama.

- 385 -
1. OPŠTI METOD IMPLEMENTACIJE PROGRAMA/SISTEMA
ZAŠTITE

U praksi zaštite postoje dva glavna metoda da se implementiraju

programi i sistemi reaktivne i proaktivne zaštite od dinamiĉki
promenljivih pretnji (DPP), [6]:

1. sveobuhvatnim ublaţavanjem ukupnog rizika na prihvatljivi nivo

i
2. procesom 4-fazne tranzicije iz jednog u drugo bezbednosno
stanje.

Smanjenje ukupnog rizika za sve objekte IKT sistema na prihvatljiv nivo,

dugoroĉan je i zahtevan proces koji podrazumeva sveobuhvatni sistemski
pristup i smanjenje svih faktora rizika na prihvatljiv nivo izborom i
implementacijom adekvatnih (rentabilnih) upravljaĉkih, operativnih i
tehniĉkih kontrola zaštite.

Umesto sveobuhvatnog sistemskog pristupa sa pokušajem istovremene

zaštite svakog objekta IKT sistema od svake iskoristive ranjivosti,
preporuĉuje se alternativni (cik-cak) metod implementacije programa i
sistema zaštite, korišćenjem metoda ĉetvoro - fazne tranzicije IKT
sistema iz jednog u drugo (više) bezbednosno stanje. U tom smislu treba
poći od zaštite najkritiĉnijih (najosetljivijih) objekata IKT sistema. U

- 386 -
Tabeli 1.1. dat je pregled opštih, preporuĉenih faza implementacije
programa zaštite u zavisnosti od rizika za osetljive objekte zaštite.

Faza Kritiĉni objekti za Kritiĉni Primarni Opšti objekti

misiju objekti objekti
1. 20 glavnih faktora rizika 0 0 0
(FR.)
2. 50 glavnih faktora rizika 20 glavnih FR 0 0
3. 100 glavnih faktora rizika 50 glavnih FR 20 glavnih FR 0
4. 200 glavnih faktora rizika 100 glavnih 50 glavnih FR 20 glavnih FR
FR

T. 1.1. Faze implementacije programa zaštite

Faza 1. usmerena je na zaštitu objekata kritiĉnih za misiju organizacije,

obuhvata 20 glavnih faktora rizika, pod pretpostavkom da analiza rizika
obuhvata ukupno 200 razliĉitih faktora rizika. Ovaj inicijalni korak brzo
proizvodi rezultate i omogućava zaposlenim da postanu familijarni sa
procesom proaktivne DPP zaštite. Faza 2. proširuje sistem zaštite od 20
glavnih faktora rizika i dodatno ukljuĉuje zaštitu od sledećih 50 faktora
rizika za objekte kritiĉne za misiju organizacije. Proces progresivno raste
u skladu sa sazrevanjem kapaciteta zaštite organizacije, obezbeĊujući sve
dublje nivoe zaštite kroz mreţu organizacije, servere, radne stanice i
aplikacije. Na ovom konceptu zasnivaju se metodi evaluacije operativno
kritiĉnih pretnji i ranjivosti, digitalnih objekata IKT sistema – OCTAVE
(Operationally Critical, Threat, Asset, and Vulnerability Evaluation),
[13] i metod brze analize rizika (BAR), [15]. OCTAVE omogućava
organizacijama da izborom internog tima za analizu rizika identifikuju
faktore rizika za najznaĉajnije objekte IKT sistema i izgrade plan mera
zaštite da se eliminišu ti faktori rizika. BAR analiza se vrši na
pojednostavljenoj arhitekturi IKT sistema, gde se objekti arhitekture IKT
sistema grupišu u bezbednosne zone sa objektima koji imaju iste ili sliĉne
bezbednosne ciljeve. Poĉetna taĉka je da se ignorišu svi postojeći
bezbednosni servisi, pošto ih derivira proces BAR analize. Skup rezultata
BAR analize prokazuje se tabelarno u matrici faktora rizika za svaku
definisanu bezbednosnu zonu (videti G. II. p.2). BAR analizu vrši tim
izvršnih menadţera organizacije sa specijalistom zaštite koji vodi
sastanke i proces analize.

- 387 -
U svakoj metodi ublaţavanja rizika osnovno pitanje je kako prepoznati
koji su glavni faktori rizika? Za neke poslovne sisteme, moguće je za
procenu ranjivosti sistema i primenu bezbednosnih popravki (zakrpa)
koristiti servis nekog poznatog poverljivog provajdera zaštite (TTPS-
Trusted Third Party Service), [19], koji sa svojim kapacitetima za
skeniranje i analizu mreţnog saobraćaja, prati pretnje koje se pojavljuju
na Internetu bilo gde u svetu i na jednostavan i razumljiv naĉin
dostavljaju klijentima informacije o novim pretnjama, ili po zahtevu
apliciraju bezbednosne popravke. Na osnovu ovih informacija korisnik
bira konfiguraciju sistema kontrola zaštite. MeĊutim, korišćenje usluga
TTPS provajdera zaštite nosi inherentni rizik, predstavlja znaĉajan faktor
nepoverenja korisnika i nije primenljivo za mnoge sisteme, zbog
zakonskih i drugih ograniĉenja.

Poverljivi provajderi zaštite, korišćenjem nekog od servisa DPP

proaktivne zaštite za upravljanje zaštitom (RealSecure, ISS Proventia),
obezbeĊuje proaktivnu zaštitu sa svim njenim prednostima.

- 388 -
2. IMPLEMENTACIJA PROGRAMA ZAŠTITE

U praksi zaštite proces implementacije programa zaštite moţe se u

odreĊenim aktivnostima razlikovati u razliĉitim organizacijama, za
razliĉite ciljeve i okruţenja. Generalno tok procesa implementacije
programa zaštite odvija se u 4 faze, [15]:

1. Izbor tima za koordinaciju i monitorisanje.

2. Identifikovanje bezbednosnih faktora rizika, racionalno
procenjenih internih i eksternih, za poverljivost integritet i
raspoloţivost informacija, ukljuĉujući rizik zbog nedostatka
obuke (menadţera za upravljanje, zaposlenih za rad u IKT
sistemu: procesiranje, skladištenje, prenos, ili odlaganje
informacija) i kapaciteta za upravljanje kompjuterskim
incidentom.
3. Obavezna kontrola (revizija), najmanje jedanput godišnje od
strane kvalifikovanih lica, ukljuĉujući kontrolu usklaĊenosti sa
dokumentima zaštite, kontrolu efikasnosti programa i preporuke
za izmene i
4. Integracija i prilagoĎavanje programa u skladu sa nalazima i
preporukama iz procesa nadzora i kontrole i svim promenama
koje mogu uticati na program.

Svaki proces implementacije programa zaštite treba da obuhvata tri jasno

diferencirane i obavezne komponente sadrţaja, [1]:

1. obuku zaposlenih,
2. kontrolu usklaĎenosti i
3. nametanje obaveze izvršavanja politika i procedura zaštite.

- 389 -
2.1. Obuka zaposlenih

Da bi program zaštite bio efikasan politika i procedure zaštite

moraju biti prenete i dobro objašnjene svim zaposlenima. Od zaposlenih
se ne moţe oĉekivati da budu odgovorni, ako nikada nisu primili
informacije iz politike zaštite i postali svesni šta se od njih oĉekuje. Bitno
je shvatiti da je kibernetiĉka bezbednost problem ljudi i procesa, u kojem
tehnologija igra relativno malu ulogu (ljudske greške zbog nedostatka
znanja, obuke i pogrešnog sprovoĊenja procedura zaštite, uzrokuju oko
80% proboja sistema zaštite). Obuka u oblasti zaštite treba da obuhvati
najmanje sledeće kategorije zaposlenih:
Svi zaposleni moraju izgraditi svest o potrebi zaštite, kroz adekvatnu
formu obuke, gde treba predstaviti osnovne koncepte zaštite
poverljivosti, integriteta i raspoloţivosti informacija, aplikacija i servisa,
kao i etiĉke principe bitne za kreiranje bezbednosne kulture u
organizaciji.
Tehničko osoblje zahteva obuku o korišćenju i odrţavanju opreme i
programa, koje zaposleni koriste u izvršavanju svojih radnih obaveza.
Sistem administratori i članovi CIRT (Computer Incident Response
Team) – interventnog tima za upravljanje kompjuterskim incidentom,
zahtevaju specijalizovanu obuku za reagovanje i upravljanje sa
kompjuterskim incidentom, izbegavanje incidenta, analizu dogaĊaja,
redukciju ranjivosti sistema, oporavak sistema i nastavak poslovanja.
Tehnologija ne moţe sama rešiti problem kompjuterskog incidenta; taj
proces zahteva eksperte u oblasti IKT sistema, zvaniĉne policijske organe
istrage i specijalizovanu tehnologiju za digitalnu forenziĉku istragu,
akviziciju i analizu.
Upravna struktura mora da razume svoju ulogu u definisanju politike
zaštite i kontroli (superviziji) realizacije programa zaštite. Upravna
struktura treba da ima periodiĉne brifinge iz zakonskih, organizacionih i
tehniĉkih oblasti razvoja, koje mogu uticati na njihov rad i plan
poslovanja. TakoĊe, moraju imati bezbednosnu obuku za korišćenje
savremene beţiĉne tehnologije koju koriste u svakodnevnom radu
(mobilni telefon, PDA, Lap Top i.t.d.).
Izvršni menadžeri treba da završe obuku o svojim odgovornostima u
kreiranju bezbednosne kulture i obezbeĊivanju implementacije i
usaglašenosti programa zaštite, kao i obuku za operativno upravljanje
sistemom zaštite.
Operativno osoblje zahteva dodatnu obuku o elementima politike i
procedura zaštite, koje se primenjuju u domenu njihove odgovornosti.

- 390 -
Oni moraju razumeti plan zaštite i svoje dnevne radne obaveze prema
tom planu. Moraju biti svesni pretnji za IKT sistem i da: korektno koriste
IKT kapacitete, minimiziraju bezbednosni rizik, razumeju svoje
specifiĉne odgovornosti u zaštiti, kako postupati u sluĉaju anomalija,
sumnjivih incidenata, kako i kome dostavljati izveštaje i sl.

Ljudski resurs je kljuĉan za zaštitu IKT sistema. Dokument politike

zaštite treba da eksplicitno i jasno istakne da će zaposleni imati
adekvatnu obuku za odrţavanje znanja, veština, sposobnosti i svesti o
potrebi zaštite na nivoima, potrebnim za efikasno izvršavanje radnih
obaveza. Politika zaštite mora biti regularno revidirana i kontrolisana kao
i program zaštite.

- 391 -
2.2. Kontrola usklaĊenosti

Stepen integracije implementiranog programa i sistema zaštite u

IKT sistemu meri se stepenom usklaĊenosti programa i politika sa
zakonima i standardima, sa jedne strane i prakse zaštite sa politikama
zaštite, sa druge strane.

Kontrolu opšte usklaĎenosti programa i politika zaštite sa normativima i

standardima zaštite i za implementaciju procesa koji nameće tu politiku
obezbeĊuje (i odgovorna je) upravna struktura.

Monitoring zaposlenih o korišćenju IKT je najlakši naĉin da se nadgleda

normativna usklaĊenost politike i procedura, ali moţe biti u sukobu sa
zakonom o zaštiti privatnosti zaposlenih. U većini organizacija u
drţavnom i privatnom sektoru, ne oĉekuje se da zaposleni rade bilo šta
privatno na raĉunarima na poslu, pa u brojnim drţavama nisu zaštićeni
zakonom o zaštiti privatnosti i liĉnih podataka. U javnom sektoru
drţavne uprave u većini razvijenih zemalja zaposleni su zaštićeni
Zakonom o zaštiti ličnih podataka i na raĉunarima na poslu. Poslodavac
je obavezan da upozori zaposlene da su svi podaci pod stalnim
nadzorom. EU je obezbedila mnogo veću zaštitu privatnosti u privatnom
i javnom sektoru, jer ima sveobuhvatan zakon o zaštiti privatnosti koji se
sve više globalno prihvata. Prema direktivi EU o zaštiti privatnosti moţe
se monitorisati, [15]:

 pristup Internetu i filtriranje paketa,

 korišćenje e-pošte,
 saobraćaj brzih poruka,
 korišćenje telefona,
 lokacija zaposlenog (video nadzor) i
 logovanje otkucaja tastature.

U SAD zakon Electronic Communication Privacy Act od 1996 štiti

privatnost zaposlenih na radnom mestu (2001 oko 75% kompanija u
SAD snimalo je i monitorisalo sav saobraćaj svojih zaposlenih). Prema
tome zakonu, ako poslodavac upozori zaposlenog da se vrši nadzor, sud
to priznaje kao pristanak zaposlenog. U Republici Srbiji u toku je izrada
nacrta sliĉnog zakona za zaštitu poverljivosti i privatnost liĉnih podataka
u informacionim sistemima.

- 392 -
Kontrola specifične usklaĎenosti prakse zaštite sa primenjenim
standardima politike i procedura zaštite, kao i sa planom zaštite zahteva
ispitivanje (verifikaciju):

 poslovnih procesa i
 operativnog korišćenja tehnologija zaštite.

Za usklaĊenost politike i prakse zaštite odgovorni su zaposleni i izvršioci,

ako su za to na vreme obuĉeni. Dakle, nije dovoljno napisati politiku
zaštite i staviti je u arhivu. Zaposleni moraju biti osposobljeni i svesni
potrebe zaštite. Obuku zaposlenih mora pratiti obavezno testiranje
usvojenih znanja, veština i sposobnosti. Sve više su u upotrebi
elektronski interaktivni oblici politike zaštite, koji podrazumevaju da
korisnici imaju raĉunar, na kojem se pre pristupa informacijama pojavi
prozor koji zahteva afirmativno slaganje za prihvatanje uslova (izjava,
saopštenja) politike zaštite pre pristupa informacijama, aplikacijama ili
mreţi. Iako nije verovatno da se saĉini ovakav program obuke za celu
politiku zaštite, pogodan je barem za najviše faktore rizika, kao što su:

 pristup i korišćenje Interneta,

 korišćenje e-pošte i
 pristup zaštićenim informacijama.

Sve izjave politike zaštite treba dokumentovati u glavnom uputstvu ili

priruĉniku zaštite organizacije. Preporuĉuje se obuka i testiranje iz
oblasti zaštite tri puta godišnje.

Na primer, administratori zaštite nalaze instalirane neovlašćene modeme

i podatke kritiĉne za rad, uskladištene na ĉvrstom disku (HD) radnih
stanica umesto na HD servera i uobiĉajeno zapaţaju da zaposleni koriste
preĉice, što su sve indikatori nenamernih, potencijalno negativnih
posledica.

Za validaciju programa i plana zaštite potrebno je konstantno merenje

usklaĊenosti procedura, politike i plana sa primenjenim principima i
standardima zaštite. Ovo sve više postaje obaveza svake organizacije, jer
na taj naĉin organizacija u sluĉaju potrebe dokazuje pravosudnim
organima da su njene informacije zaštićene. Da bi ovo obezbedile
organizacije moraju primenjivati standardne procese, tehnologije, servise
i regularna merenja nivoa usklaĊenosti prakse sa programom zaštite.

- 393 -
Na primer: Ako organizacija ţeli osigurati svoj sistem u kibernetiĉkom
prostoru kod nekog osiguravajućeg društva, validacija usklaĊenosti sa
standardima za zaštitu informacija koristi se kao kriterijum za
odreĊivanje visine premije osiguranja.

 U sluĉajevima civilne parnice gde je sistem bio kompromitovan i

iskorišćen za napad na neku organizaciju, verifikacija usklaĊenosti i
konzistentne primene standarda za zaštitu informacija, dokazuje
ĉinjenicu da se oštećena strana pridrţavala standarda zaštite i da ima
pravo na nadoknadu štete.
 Verifikacija usklaĊenosti i konzistentne primene standarda za zaštitu
informacija ilustruje poslovnim partnerima da organizacija efikasno
upravlja sistemom za zaštitu, što moţe doneti veće poverenje kod
poslovnih partnera.

Većina organizacija vrši internu kontrolu (audit), dok druge više vole
eksternu, nezavisnu evaluaciju. One organizacije koje redovno vrše
interni nadzor sistema zaštite, lakše obavljaju eksternu kontrolu (audit)
kada god to zatreba.

- 394 -
2.3. Interni nadzor i kontrola

Interni nadzor (monitoring) igra kljuĉnu ulogu u zaštiti kibernetiĉkog

prostora. Ovaj nadzor obezbeĊuje kljuĉne informacije za nezavisnu
procenu rizika, analizu kompetentnosti interne kontrole, ispitivanje nivoa
usklaĊenosti sa zakonima i standardima. Cilj monitoringa sistema zaštite
je da se evaluira adekvatnost i efikasnost zaštite na Internetu, kao i da se
proaktivno aktivira upravna struktura u procesima identifikovanja novih
faktora rizika i razvoja strategije za ublaţavanje rizika. Monitoring moţe
biti:

 posebni nadzor sistema zaštite mreţne infrastrukture,

 procena adekvatnosti IDS/IPS, ili
 procena kapaciteta upravne strukture i.t.d.

Učestanost monitoringa treba da se zasniva na zdravoj logici: što su veći

faktori rizika i vrednosti objekata sistema, interni nadzor treba biti ĉešći.
Preporuke interesne zajednice za zaštitu su da se najmanje jednom
godišnje procenjuje rizik, a na osnovu te procene pravi plan za interni
nadzor. Gde je moguće, treba razmatrati implementaciju automatskog
sistema za nadzor.

Metod monitoringa: Od velike pomoći je alat za automatsku procenu

ranjivosti i oporavak IKT sistema. Sve više se predlaţe uvoĊenje
automatskih softverskih alata – skenera zaštite za skeniranje ranjivosti
sistema (RS i RM) i praćenje stanja u kibernetiĉkom prostiru, za
verifikaciju efikasnosti zaštite i neprekidno praćenje tekućeg rizika.

Obim monitoringa: Organizacije najĉešće previĊaju aspekt personalne

zaštite u procesu internog nadzora i kontrole. Prvi i najvaţniji zadatak je
da se kontroliše da li je za svaku grupu/pojedinca uspostavljena
odgovornost i dodeljeni adekvatni nalozi sa pravima i ograniĉenjima
pristupa i aktivnosti na objektima IKT sistema. Drugi aspekt personalne
zaštite je bezbednosna provera zaposlenih i gde je neophodno, davanje
bezbednosnih dozvola za rad na osetljivim radnim mestima i mestima sa
pravima pristupa osetljivim podacima.

- 395 -
U okviru programa internog nadzora i kontrole, tim za interni nadzor i
kontrolu treba da proveri postojanje sledećih komponenti zaštite:

 politika fiziĉke i logiĉke kontrole pristupa,

 korisniĉki nalozi i kontrolisane odgovornosti za nametanje politike
zaštite,
 robustan proces analize rizika, posebno za kritiĉne objekte zaštite,
 usklaĊenost sa politikom kontrole pristupa i upravljanjem nalozima i
ovlašćenjima za pristup objektima IKT sistema,
 mehanizme autentifikacije,
 liste kodiranja,
 plan upravljanje promenama konfiguracije,
 kontrolu sesija,
 politiku zaštite mreţe,
 politiku pristupa Internetu,
 kriptografske tehnologije za prenos i skladištenje,
 politiku daljinskog pristupa mreţi,
 sistem administracije procesa i procedura,
 plan i kapacitete za upravljanje incidentom (odgovor na incidente i
izveštavanje),
 plan i praksu nadzora i kontrole sistema zaštite,
 kapacitete za spreĉavanje i suprostavljanje napadima virusa i drugih
DoS (Denial of Services) napada,
 sistem bekapovanja,
 odrţavanje,
 identifikaciju osetljivosti informacija i upravljanje informacijama,
 saniranje medija i odlaganje,
 fiziĉku zaštitu,
 personalnu zaštitu,
 obuku i svest o potrebi zaštite,
 usklaĊenost sa primenljivim standardima i zakonima zašite.
 plan upravljanja vanrednim dogaĊajima i nastavljanja poslovanja.

Za proces interne kontrole standardi zaštite preporuĉuju rutinske veţbe i

simulacije vanrednih dogaĊaja, što je vaţno iz najmanje tri razloga:

1. istiĉe znaĉaj efikasne i efektivne kontrole,

2. obezbeĊuje uspostavljanje prioriteta zaštite i
3. obezbeĊuje da obuĉeni interventni tim upravlja sa kompjuterskim
incidentima razliĉitih nivoa intenziteta.

- 396 -
2.4. Eksterna kontrola (auditing)

Spoljna kontrola moţe imati zadatak da izvrši neke dodatne

kontrolne funkcije, a to su najĉešće reinţenjering procesa za povećanje
efikasnosti i smanjenje troškova poslovanja. MeĊutim, ukljuĉivanje
spoljne kontrole unosi dodatni bezbednosni rizik, koji se mora razmatrati.

Spoljni kontrolori treba da uspostave konstruktivne odnose sa internom

IKT upravnom strukturom. Spoljni kontrolor treba da ima edukativnu i
savetodavnu ulogu za interno osoblje za zaštitu, o tome kako da
procenjuje i kontroliše bezbednosni rizik u IKT, kada organizacija
donese odluku da implementira nove tehnologije. Spoljna kontrola se
mora izvršiti u bezbednom okruţenju u atmosferi poverenja i uz
prisustvo internog specijaliste za nadzor i kontrolu, a uz odobrenje
nadleţnog organa organizacije.

Vaţno je da lica za nadzor i kontrolu neprekidno prate konstantan razvoj

tehnologije zaštite, najbolju praksu zaštite, pojavu novih standarda i
trendova u oblasti kompjuterskog kriminala.

- 397 -
2.5. Izveštavanje o kontroli zaštite

Dokumentacija o kontroli zaštite kibernetiĉkog prostora obuhvata

izveštaj o radu interne i eksterne kontrole sistema zaštite. ISACA
(Information System Audit and Control Association) predlaţe listu od
nekoliko potencijalno korisnih upotreba te dokumentacije i to da, [20]:

 pokaţe koji sistem mera je koristio kontrolor (auditor),

 pomogne u planiranju, izvršavanju i kontroli rada auditor-a,
 ako je potrebno, olakša TTPS da izvrši reviziju rada kontrolora,
 evaluira sistem kvaliteta programa kontrole,
 obezbedi podršku u sluĉaju zahteva za naplatu polise osiguranja, kao
i u sluĉaju zloupotreba ili sudskog gonjenja,
 pomogne u profesionalnom razvoju specijalista za zaštitu i.t.d.

Kontrola aplikacija: Efikasan kontrolor sistema zaštite treba da izvrši

kontrolu svake aplikacije i OS i da se uveri da su bezbedni. Uzimajući u
obzir da su aplikacije uglavnom komercijalni proizvodi, ĉesto postoje
ranjivosti i inherentni bagovi koji su izvan uticaja kontrole organizacije,
ovaj zadatak obuhvata ĉetiri glavne aktivnosti:
 pripremiti kriterijume koji obezbeĊuju konzistentnost aplikacija sa
poslovnom politikom organizacije,
 nametnuti politiku zaštite kroz preventivne kontrole,
 ukazati na rezultate kontrole politike zaštite u izveštaju i
 preporuĉiti komplementarne radne procedure za aplikacije.

Shodno tome, kada se implementira politika kontrole aplikacije,

kontrolor ne samo da mora razmatrati kljuĉne komponente zaštite, nego i
uzeti u obzir ţivotni ciklus aplikacije i upravljanje zaštitom samog
proizvoda.

Automatizovana kontrola (predlog zamene sistema kontrole): Spoljni

kontrolor (auditor) moţe evaluirati i predloţiti zamenu sistema kontrole
sa automatizovanim sistemom kontrole IKT zaštite, koji zamenjuje
ljudski faktor, konsultujući pri tome organizaciju oko adekvatnosti i
prihvatljivosti predloţenog sistema automatskog nadzora i kontrole.

- 398 -
Kontrola politika zaštite: Druga funkcija kontrolora (auditora) je da u
izveštaju o kontroli konstatuje aţurnost politika zaštite i verifikuje
usaglašenost prakse zaštite sa propisanom politikom. U izveštaju
kontrolor treba da:

 navede nivo usaglašenosti prakse zaštite sa politikom zaštite,

 sugeriše poboljšanje usaglašenosti prakse i politike zaštite,
 sugeriše aţuriranje i osavremenjavanje politike zaštite,
 navede sisteme i situacije koji nisu adekvatno obraĊeni u politici i
uputstvu za zaštitu.

Format izveštaja o kontroli sistema zaštite: ISACA daje preporuku za

format dokumenta za kontrolu (audit) i nadzor, koji treba da sadrţi:

 plan i pripremne aktivnosti (definisani obim i ciljevi kontrole),

 program kontrole (sadrţaj rada),
 faze izvoĊenja kontrole i dokazi koje treba skupljati,
 nalazi kontrole, zakljuĉci i preporuke i
 pregled i nalaz supervizorske kontrole.

Svest o potrebi zaštite: Uspešan kontrolor takoĊe koristi izveštaj o

kontroli kao materijal za razvoj svesti o potrebi zaštite kod IKT
korisnika, glavnih menadţera, izvršnih menadţera i administratora
sistema. Razvija se svest o potrebi izveštavanja o kompjuterskim
incidentima i sluĉajevima zloupotreba i kompjuterskog kriminala, a
izveštaji o kaţnjavanju hakera i drugih kompjuterskih kriminalaca sluţe
kao faktori odvraćanja, što je korisno za svaku organizaciju.

Strategijski ciljevi: U izveštaju o svom poslu kontrolori mogu dodati i

dugoroĉni cilj kontrole zaštite za strategijski plan zaštite, usklaĊen sa
glavnim, poslovnim ciljevima organizacije.

Korišćenje pravnih saveta u procesu kontrole: Uloga pravnika

organizacije u zaštiti poverljivosti podataka i informacija u procesu
kontrole i nadzora moţe biti znaĉajna. Treba imati na umu da pravnik
organizacije ima privilegiju i obavezu da štiti poverljive informacije
klijenata i organizacije, što ipak nije potpuna garancija da ne moţe doći
do otkrivanja podataka i informacija.

- 399 -
2.6. Nametanje obaveze izvršavanja i izveštavanja

Nametanje obaveze izvršavanja i izveštavanja je sledeći logiĉan

korak koji sledi obuku, nadzor i kontrolu usaglašenosti prakse i politike
zaštite. Izveštaj o nadzoru i kontroli je ulazna informacija za
reinţenjering programa i politike zaštite u organizaciji i korekciju
eventualno slabih taĉaka u sistemu zaštite. MeĊutim, ĉesto se politika i
procedure zaštite planiraju i implementiraju bez represivnih mehanizama
za nametanje obaveze izvršavanja, što je kritiĉan faktor, jer ako nema
posledica za povrede politike zaštite, zaposleni je neće dosledno
sprovoditi. Ove sankcije za nesprovoĊenje politike zaštite moraju biti
dobro i unapred osmišljene, a mogu se kretati od upozorenja do
otpuštanja sa posla, ili sudskog gonjenja. Za organizaciju nema smisla
razvijati program, politiku i procedure zaštite i implementirati
mehanizme i protokole zaštite ako se povrede sistema zaštite ignorišu. Da
bi se spreĉilo otpuštanje zaposlenih i obeshrabrili napadaĉi iznutra,
nadzor i kontrola sistema zaštite, kao i odgovori na sve incidente moraju
biti pravovremeni, potpuni i efikasni. Moraju se poštovati nacionalni i
EU zakoni, principi i standardi za borbu protiv zloupotreba IKT i
kompjuterskog kriminala, kao i za istragu, akviziciju i analizu digitalnih
dokaza, radi obezbeĊivanja meĊunarodne saradnje u hapšenju napadaĉa
sa Interneta.

- 400 -
3. REZIME

U praksi zaštite postoje dva glavna metoda za implementaciju

programa i sistema reaktivne i proaktivne zaštite od dinamiĉki
promenljivih pretnji: sveobuhvatnim smanjenjem ukupnog rizika na
prihvatljivi nivo i procesom 4-fazne tranzicije iz jednog u drugo
bezbednosno stanje.

Umesto sveobuhvatnog sistemskog pristupa sa pokušajem istovremene

zaštite objekta IKT sistema od svake iskoristive ranjivosti, preporuĉuje se
metod ĉetvoro - fazne implementacije programa i sistema zaštite, gde se
u 1. fazi obezbeĊuje zaštita objekata kritiĉnih za misiju organizacije od
kljuĉnih faktora rizika, a u sledećim fazama progresivno razvija i
implementira program zaštite ostalih objekata od svih ostalih faktora
rizika. Proces progresivno raste u skladu sa sazrevanjem kapaciteta
zaštite organizacije, obezbeĊujući sve dublje nivoe zaštite kroz RM
organizacije, servere, radne stanice i aplikacije.

Proces implementacije programa zaštite odvija se u 4 faze: izbor tima za

koordinaciju i monitorisanje; identifikovanje internih i eksternih
bezbednosnih faktora; izvršavanje obavezne godišnje kontrole (revizije) i
usklaĎivanje programa zaštite prema nalazima i preporukama procesa
kontrole i nadzora.

Sam proces implementacije programa zaštite obuhvata tri jasno

diferencirane komponente: obuku zaposlenih, kontrolu usklaĎenosti i
nametanje obaveze izvršavanja politika i procedura zaštite. Obuka treba
da obuhvati sve strukture zaposlenih: korisnike, tehniĉko osoblje,
zaposlene u IKT i sistemu zaštite, menadţersku strukturu i operatere u
IKT sistemu i zaštiti. UsklaĊenost obuhvata dve komponente usklaĊenost
programa i politike zaštite sa zakonima i standardima zaštite i
usklaĊenost prakse i politike zaštite. Obaveze sprovoĊenja programa i
politika zaštite nameće se merama internog nadzora i kontrole i eksterne
kontrole (auditing), obaveznog izveštavanja o bezbednosno relevantnim
dogaĊajima i sankcionisanjem nesprovoĊenja politika zaštite.

- 401 -
4. KLJUĈNI TERMINI

Akvizicija digitalnih dokaza: poĉinje kada su informacije i/ili fiziĉki

predmeti skupljeni i uskladišteni za potrebe ispitivanja. Termin DE
implicira da je skupljanje DE obavio neko koga sud prepoznaje, da je
proces skupljanja DE legalan i u skladi sa zakonskom regulativom i da je
skupljeni materijal sud prihvatio kao dokazni materijal.. Objekti podataka
i fizikalni objekti postaju dokazi samo kada ih takvim vide regularni
zvaniĉni organi istrage.
Digitalni dokazi: svaka informacija koja ima dokazujuću vrednost koja
je ili uskladištena ili prenesena u binarnoj (digitalnoj) formi; ukljuĉuje
kompjuterski dokaz, digitalni audio, digitalni video, mobilni telefon,
digitalnu fax mašinu i.t.d.; informacija uskladištena ili prenesena u
binarnoj formi na koju se sud moţe osloniti.
Plan zaštite: sveobuhvatan strategijski dokument za zaštitu objekata IKT
sistema. IzraĊuje se u procesu razvoja Programa zaštite. Zasniva se na
realnom modelu upravljanja rizikom i analize rizika, realnoj arhitekturi
sistema i treba biti dovoljno detaljan, jasan i precizan. U tom smislu u
Planu zaštite potrebno je precizno definisati sve relevantne termine:
korisnik, digitalni objekti, liĉni podaci, poverljivi podaci i informacije,
osetljivi neklasifikovani podaci i.t.d. Dokument Plan zaštite predstavlja
plan implementacije politika i procedura zaštite.
Politika zaštite organizacije: kljuĉna komponenta programa (i plana)
zaštite, izjava na visokom nivou koja obezbeĊuje okvir oĉekivanog i
obaveznog ponašanja upravne strukture, zaposlenih, tehnologije i procesa
kroz instrukcije, procedure, pravce aktivnosti i principe rada koji su
obavezni za organizaciju; naĉin na koji neki entitet (organizacija,
institucija) upravlja, štiti i distribuira poverljive podatke i informacije;
definiše ko moţe imati pristup kojoj informaciji i koje aktivnosti moţe
obavljati: ĉitanje, pisanje, dodavanje i brisanje podataka; obezbeĊuje
meĊusobno poverenje uĉesnika, što je od fundamentalnog znaĉaja.
Procedure zaštite: precizno definisani naĉini primene elemenata politike
zaštite sa listom detalja i specifiĉnih koraka koje pojedinci moraju
koristiti dok izvršavaju procese; spuštaju politiku zaštite na operativni
nivo i objašnjavaju kakao se implementira politika zaštite za dnevni rad;
usklaĊenost prakse i politike zaštite u velikoj meri zavisi od toga kako su
kompletne procedure i koliko dobro definišu i opisuju radnje koje treba
preduzeti da bi se zadovoljili bezbednosni zahtevi.

- 402 -
Program zaštite: programska politika zaštite na najvišem nivou, koja
predstavlja smernice za izradu, politika i procedura zaštite i detaljnog
plana za implementaciju politika zaštite.
Digitalna forenzika: skup procesa istrage (praćenja traga napadaĉa),
otkrivanja (akvizicije-izvlaĉenja digitalnih podataka), analize (stvaranja
ĉvrstih i neoborivih digitalnih dokaza) i pripreme digitalnih dokaza za
pravosudne potrebe (veštaĉenje) u sluĉaju zloupotrebe i kompjuterskog
kriminala.

- 403 -
5. LITERATURA:

1. American Bar Association, Section of Science &Technology

Law, Privacy & Computer Crime Committee, International
Strategy for Cyberspace Security,
www.abanet.org/abapubs/books/cybercrime, 2003.
2. Harold F. Tipton, Micki Krause: The information security
handbook, 4th izdanje vol.2.CRC Press LLC, 2001.
3. html://www.oecd_1997_guidlines_ policyKz, Paris, 1997.
4. http://www.cert.org/incident_notes/index.html.
5. http://www.ciac.org/ciac.
6. http://www.sans.org/resources/errors.php
7. ISS, Dynamic Threat Protection™ : A New Definition for
Information Security, http://www.iss.org, 2005.
8. Karygiannis L. O., Wireless Network Security: 802.11, Bluetooth
and Handheld Devices, NIST SP 800-48,
http://www.nist.gov/publications, novembar 2002.
9. Matthew G. Naugle, Network Protocol Handbook, McGraw-Hill,
1999.
10. Naval Research Laboratory, Handbook for the Computer Security
Certification of Trusted Systems,
http://www.itd.nrl.navy.mil/ITD/5540/publications/handbook, 1995.
11. NIST SP 800-12, An introduction to computer Security- The NIST
Handbook, , http://csrc.nist.gov/publications, 1997.
12. NIST SP 800-14, Genaerally Accepted Principles and Practices
for Security, http://csrc.nist.gov/publications, 2002.
13. NIST SP 800-18, Guide for developing Security Plans for IT
Systems, http://csrc.nist.gov/publications, 1998.
14. OCTAVE®Method Implementation Guide,
http://www.cert.org/octave/osig.html, 2004.
15. OECD, The Cryptography Policy: Guidelines and the Issues,
16. Purser S., A practical guide to managing information security,
Artech House, Boston, London, http://www.artechhouse.com,
2005.
17. RFC 2196, Site Security handbook, www.rfc.com, (1997).
18. Stoneburner G., Hayden C. and Feringa A., Engineering
Principles for Information Technology Security (A Baseline for
Achieving Security), NIST SP 800-27,
http://csrc.nist.gov/publications, 2004.

- 404 -
19. The Canadian Handbook on Information Technology (IT)
Security, www.canada.gov.itsec.com, 1999.
20. UK Department of Industry: A Taxonomic Model of Trusted Third
Party Services, Gamma Secure Systems, Diamond House,
Frimley Road, Camberley, 2002.
21. www.isaca.com, 2003.

- 405 -
9. METRIĈKI SISTEMI U OBLASTI ZAŠTITE INFORMACIJA

0. UVOD

Po završetku ovog poglavlja razumećete:

- definicije «»merenja», »metrike» i «metričkog sistema»

- vrste i značaj metrika u oblasti zaštite IKT sistema
- proces razvoja metrike i metričkog sistema
- metriku zrelosti procesa zaštite na bazi SSE CMM modela

U sistemu zaštite informacija ni jedna aktivnost ne moţe biti

dobro upravljana ako se ne moţe izmeriti. Ciljevi zaštite raspoloživosti,
integriteta i poverljivosti informacija, primarno usmereni na zaštitu
informacija u IKT sistemu, mogu se odrediti na bazi: bezbednosnih
zahteva (n.p.r., ISO/IEC 15408, CC), kontrola najbolje prakse zaštite
(n.p.r., ISF V.4), sistema osnovnih kontrola zaštite (n.p.r., ISO/IEC
17799), upravljanja sistemom zaštite na bazi iskustva (poboljšavanjem
procesa zaštite) i primene metrike modela progresivnog sazrevanja
procesa zaštite (n.p.r., SSE-CMM), [4].

Razvoj programa metriĉkog sistema zaštite ukljuĉuje izbor metodologije:

definisanje objekata zaštite za merenje, izbor tipa, razvoj procesa i
implementaciju metriĉkog sistema. Dobra metodologija metrike zaštite
zahteva poznavanje i primenu generiĉkog procesa metriĉkog sistema.
IzmeĊu više metodologija za testiranje i garanciju kvaliteta proizvoda i
sistema zaštite, paţnju zasluţuje model i metod za progresivni razvoj
sazrevanja procesa zaštite-SSE-CMM (System Security Engineering
Capability Maturity Model). U Standardu ISO/IEC 15443 navedene su
sve metode i sredstva za kontrolu kvaliteta i to bazirane na: procesnom
pristupu (SSE-CMM, ISO 9000-3, ISO 9001, ISO/IEC 15504 i.t.d.),
pristupima proizvod/sistem/servis zaštite (CC/CEM, ITSEC/ITSEM,
TCSEC/TPEP, ISO/IEC 9646, ISO/IEC 14598 i dr.) i na pristupu
okruženju (TCMM, ISO 13407 i dr.).

- 406 -
1. METODOLOGIJA SISTEMA MERENJA ZAŠTITE
INFORMACIJA

1.1. Definicije pojmova

Merenje se definiše kao jednokratni uvid u specifiĉne merne

parametre komponente/sistema zaštite. U praksi zaštite razvijeno je više
metoda za merenja nivoa zaštićenosti informacija: analiza rizika;
kontrola (auditing); sertifikacija; merenje upada u sistem (IDS/IPS);
nadzor performansi sistema zaštite (mreţni skeneri); testiranje sistema na
proboj (simulacija malicioznih napada) i.t.d. U svim ovim metodima
koriste se brojne metrike i metrički sistemi.

Metrika je višekratno merenje u duţem vremenskom periodu ili sredstvo

za interpretaciju agregiranih podataka merenja (mernih podataka) na
višem nivou (organizacije). Zahtevani merni podaci moraju biti dostupni,
a razmatrani procesi merljivi, konzistentni, stabilni i ponovljivi. Metrika
mora obezbediti kvantitativne merne jedinice koji se mogu uporeĊivati,
od jednog do drugog merenja i primenjivati za analizu i praćenje
promena korišćenjem istih referentnih mernih vrednosti, najĉešće:
procentni račun, srednja vrednost i apsolutni brojevi. Metrika
monitoriše stepen postizanja taktiĉkih (goals) i strateških (objecives)
ciljeva zaštite: kvantifikovanjem nivoa implementacije, efektivnosti i
efikasnosti kontrola zaštite; analizom adekvatnosti procesa i kontrola
zaštite i identifikovanjem mogućih akcija za njihovo poboljšavanje, [10].

Primer: „Svi zaposleni moraju završiti adekvatni kurs i usvojiti program

za podizanje svesti o potrebi zaštite― (Strateški cilj), a odgovarajući
taktički ciljevi: „Svi novi zaposleni moraju završiti program obuke za
novo zaposlene―, „Obuka zaposlenih uključuje osnove Pravila i
ponašanja u IKT sistemu― i „Obuka zaposlenih uključuje osnove
politika i procedura zaštite na nivou organizacije―.

Metrički sistem je skup kriterijuma, parametara, mernih podataka i

jedinica za izraţavanje rezultata merenja, koji uobiĉajeno podrazumeva
procese evaluacije (auditing, analiza ranjivosti, testiranje na proboj) i/ili
monitoringa performansi servisa zaštite (tehniĉki sistem metrike, log
datoteke). Metriĉki sistemi u oblasti zaštite informacija su brojni, a u
praksi zaštite najĉešće se primenjuju: snaga kriptografskog algoritma;
kvalitativna metrika (npr. uticaja: nizak, srednji, visok); kvantitativna

- 407 -
metrika (cost - benefit); metrika softverskog inţenjerstva (SwE), [5, 8];
detekcija anomalija (IDS/IPS); srednje vreme napada; intervju; metrika
poslovnih procesa; metrika kontrole sistema zaštite (auditing) i SSE-
CMM metrika sazrevanja procesa zaštite.

Objekti merenja u sistemu zaštite informacija mogu biti: organizacija;

proizvod (planiran, u razvoju, u radu); tehnički sistem (hardver, softver,
komunikaciona infrastruktura, komponente sistema zaštite, sistem zaštite
u celini).

- 408 -
1.2. Principi, namena i proces metriĉkog sistema

Glavni principi metriĉkog sistema zaštite su: obezbeĎene

informacije koje se mogu kvantifikovati (procenti, srednje vrednosti,
gradacije 1-3 , 1-5, 1-10); uvek dostupni podaci koji podržavaju metrički
sistem; samo ponovljivi procesi mogu se smatrati merljivim;
upotrebljivost za praćenje performansi sistema zaštite i usmeravanje
resursa.

Namena metriĉkog sistema zaštite je da identifikuje uzroke slabih

performansi sistema zaštite (servisa i mehanizama) i omogući
odgovarajuće korektivne akcije. Moguće je razviti tri tipa metričkih
sistema zaštiti, za merenje:

1. kvaliteta implementacije politika zaštite;

2. efektivnosti i efikasnosti servisa zaštite;
3. uticaja bezbednosno relevantnih dogaĎaja na poslove i misiju
organizacije.

Efektivnost svakog tipa metriĉkog sistema zavisi od zrelosti programa

zaštite organizacije i kvaliteta implementacije kontrola zaštite IKT
sistema. Iako se sva tri tipa metriĉkih sistema mogu koristiti simultano,
sa povećanjem zrelosti implementacije kontrola zaštite, primarni fokus se
pomera od prvog do trećeg tipa metriĉkog sistema.

Generički tok procesa metriĉkog sistema zaštite informacija (Sl. 1.2) u

prvom koraku definiše ciljeve zaštite i njihove meĊuzavisnosti. Zatim se
vrši analiza i izbor komponenti metriĉkog sistema. U sledećem koraku
pronalaze se meĊuzavisnosti i eventualno povratno koriguje izbor
komponenti metriĉkog sistema. Izlazni metriĉki sistem je sloţen i
kombinovan od više reprezentativnih metrika iz prethodnih koraka, [10].

- 409 -
 Definisanje bezbednosnih ciljeva i
meĊuzavisnosti

Analiza i selekcija metriĉkih

komponenti

Pronalaţenje meĊuzavisnosti

Formiranje integrisane metrike

Sl. 1.2. Generiĉki tok procesa metrike zaštite

1.3. Procesno-rezultatski orijentisan metriĉki sistem zrelosti procesa

zaštite

U procesnom pristupu zaštiti informacija, metriĉki sistemi mogu

meriti organizacione procese (kontrole) zaštite, kvalitet proizvoda,
performanse tehniĉkih sistema i dr., a od posebnog znaĉaja su metriĉki
sistemi za merenje sazrevanja procesa zaštite. Razvijeno je više metrika
za merenje zrelosti procesa zaštite i upravljanje programom zaštite
informacija, kao što su: SSE-CMM4 (ISO/IEC 21827; EOS, 2001),
INFOSEC IA-CMM, IS Program Maturity Grid i SW Security Metrics,
[5].

SSE-CMM meĊunarodni i evropski standard od 2001 godine, koji meri i

odreĊuje zrelost i poboljšanje procesa i kapaciteta zaštite, verovatno je
najkompletniji i najlakši za primenu od gore pomenutih metriĉkih
sistema procesa zaštite. Model sadrţi dve celine: oblast primene procesa
(Domain side) i oblast kapaciteta zaštite (Capability side), [4], [6]. Oblast
primene obuhvata 60 osnovnih praksi zaštite (BP-Basic Prctices), koje se
obavezno izvršavaju, grupisanih u 11 tehničkih oblasti procesa -(OP)
zaštite 11 upravljačkih (projektnih) i organizacionih OP zaštite. Oblast
kapaciteta modela sadrţi tri kategorije: generičke radnje (Generic
Practices)-GPs (ukupno 30), koje evaluiraju izvršavanje BP, a grupišu se

4
SSE CMM – Security System Engineering Capability Maturity Mode

- 410 -
u zajedničke karakteristike (Common Features)-CFs (ukupno 12),
rasporeĊene na 5 nivoa zrelosti kapaciteta (Capability Levels)-CLs,
(Sl.1.1), [1]. Da bi se merio progres efektivnosti implementacije kontrola
zaštite, SSE CMM model obezbeĊuje 5 nivoa efektivnosti za svaki
odgovor na kontrolna pitanja, [6]:

0.nivo – bez aktivnosti i izvršenih procesa zaštite (obiĉno se u modelu

izostavlja).
1.nivo – nekompletan, dokumentovan i neformalno izvršavan, postoji
politika zaštite
2.nivo – kompletiran i dokumentovan, postoje detaljne procedure
3.nivo – dobro definisan, implementirane i dokumentovane procedure,
4.nivo – kvantitativno meren, verifikovan i kontrolisan, testiranje
usaglašenosti sa politikom zaštite i efektivnosti procedura;
5.nivo – najviši, kontinualno poboljšavan, potpuno implementirane i
integrisane politike i procedure zaštite u dnevne operacije u celom IKT
sistemu organizacije;

SSE CMM
model

DOMEN NIVOI ZRELOSTI

(oblast primene) KAPACITETA

OBLAST ZAJEDNIČKE
PROCESA KARAKTERISTIKE
(OP) (CF)

BAZIČNE Evaluiraju GENERIČKE

PRAKSE PRAKSE
(BP) (GP)

Sl. 1.1. Struktura SSE CMM modela i metoda

Metrika zrelosti procesa zahteva brojne aktivnosti: prikupljanje dokaza o

izvršenim praktiĉnim aktivnostima, korišćenje resursa organizacije,
analizu aktivnosti internih ugovaraĉa u odnosu na snabdevaĉe, primenu
metoda merenja, taĉnost, ponovljivost i nezavisnost procesa, [6].
Za kvalitetno merenje progresivnog sazrevanja procesa treba definisati
skup mernih atributa, za: neprekidno inoviranje/optimizaciju procesa;
kvantitativno merenje procesa i nastalog proizvoda; praćenje standardnih
procesa organizacije; obezbeĊenje podrške organizacije (politike,

- 411 -
procedure, obuka); planiranje i upravljanje procesima; izvršavanje svih
kljuĉnih procesa; izvršavanje nekih delova procesa.
Merenje OP za razvoj programa zaštite, obezbeĊuje alat razvijen u SSE
CMM za merenje SSE, organizacionih i upravljaĉkih procesa sistema
zaštite. Pošto je SSE CMM zasnovan na procesima, a orijentisan na
oblast zaštite informacija, metriĉki sistem treba da obuhvati dva aspekta:
1. Specifičnu metriku procesa, orijentisanu na same procese, koja se
moţe definisati sa:
- kvantitativno/kvalitativnim dokazima o nivoima zrelosti SSE
OP, ili
- binarnom indikacijom prisustva/odsustva zrelog procesa.
2. Metriku sistema zaštite, orijentisanu na rezultate izvršavanja procesa
zaštite, koja:
- obezbeĊuje atribute merenja (objektivne/subjektivne,
kvalitativne/kvantitativne) rezultata SSE procesa, koji mogu
posluţiti kao dokaz efektivnosti tog procesa.
Opšta procedura metriĉkog sistema modela zrelosti i sazrevanja
kapaciteta procesa za razvoj programa zaštite obuhvata sledeće glavne
aktivnosti, [10]:
5. Na svakom nivou (1-5) modela ponderisati sve izabrane OP
teţinskim faktorima od 1-5 koji pozicioniraju datu OP na
odgovarajući nivo zrelosti (npr. sve OP =3 nalaze se na 3. nivou
zrelosti, sve OP=1, na 1. nivou zrelosti i.t.d.).
6. Na svakom nivou izraĉunati ukupan zbir teţinskih faktora svih
OP, koji pokazuje nivo zrelosti na datom nivou SSE CMM
razvoja programa/procesa zaštite.
7. Razlika izmeĊu zbira teţinskih faktora zrelosti OP na višem nivou
u odnosu na niţi nivo, pokazuje kvantitativnu meru progresivnog
razvoja „zrelosti― procesa i kapaciteta programa zaštite na višem
nivou.
8. Izradom osnovnog (referentnog) profila zrelosti procesa/programa
na ţeljenom nivou, primenom opšte procedure merenja i profila
sazrevanja procesa, posle odreĊenog vremena meri se tekući
profil i odreĊuju razlike zrelosti svake OP ili zbira OP na
odgovarajućem nivou kapaciteta u referentnom i tekućem profilu,
koje indiciraju nivo progresivnog sazrevanja svakog
pojedinaĉnog/zbirnog OP.

- 412 -
U procesu merenja sazrevanja procesa i kapaciteta zaštite i progresa u
razvoju programa zaštite treba imati na umu da neke OP nije moguće
primeniti (odnosno, ciljevi mogu uticati na procenu OP) i da je neke OP
teţe izvršiti (odnosno, uniformni cilj je nerealan).

U PRILOGU II 9A dat je primer primene metrike modela sazrevanja

procesa na bazi koncepta upitnika za samo-procenu (merenje) kontrola
personalne zaštite i autentifikacije u IKT sistemu hipotetiĉke drţavne
ustanove, [11].

Proizvodi zaštite kao objekti merenja, ranjivi su u fazi razvoja,

implementacije i odrţavanja, zavisno od zrelosti primenjene tehnologije,
koja se vremenski menja i stabiliše u fazi odrţavanja (sl. 1.2), pa se
merenja mogu vršiti u svim taĉkama ranjivosti, [8].

Rad i odrţavanje
Zrelost
tehnologije Ranjivost
implementacije

NIR

Ranjivost
dizajna

Istraţivanje Vreme

Sl. 1.2. Zrelost proizvoda zaštite

Tehnički metrički sistemi mogu se primeniti u više sluĉajeva, na primer

u: uspostavljanju cilja zaštite - za merenje stepena dostizanja
postavljenog cilja; planiranju nivoa zaštite – za predviĊanje nivoa zaštite
pre implementacije; implementiranom sistemu – za merenje nivoa
mogućeg upada (korišćenjem IPS sistema); usklaĎivanju – za
uporeĊivanje nivoa zaštićenosti objekata sistema zaštite u procesu
evaluacije ili merenja usklaĊenosti sa standardom i politikom zaštite;
nadzoru - za monitorisanje ili skeniranje nivoa zaštite nekog objekta

- 413 -
(npr. IDS) i u analizi - u sluĉaju primene metriĉkog sistema kao metoda
za izbacivanje grešaka. Primeri tehniĉkih alata za merenje nivoa zaštite:
IDS/IPS sistemi; skeneri za monitoring mreţne zaštite; antivirusni
programi; antišpijunski i antispam programi, mreţne barijere (firewalls)
i dr. Svi ovi ureĊaji generišu odreĊene merne podatke (rezultate merenja)
koji se smeštaju u log datoteke tehniĉkih parametara zaštite. Trend
razvoja tehniĉkih metriĉkih sistema zaštite je merenje iza IDS/IPS
sistema.

Definisanje ciljeva zaštite smatra se kljuĉnom aktivnosti u sistemskom

inţenjerstvu zaštite (SSE), višestruko znaĉajnom: generalno, u državnim
institucijama i industrijskom sektoru (Tabela T.1.1), [2].

Drţavne institucije Industrijski sektor Generalno

Izgradnja i odrţavanje Integrisanje rada IKT Razvoj svesti o potrebi
poverenja korisnika sistema u poslovne procese zaštite IKT sistema
ObezbeĊivanje
Bekapovanje poslovne
funkcionisanja kritiĉnih
strategije
procesa
ObezbeĊivanje
ObezbeĊivanje zaštite
harmonizacije glavnih
proizvoda
zadataka i normativa

T. 1.1. Znaĉaj definisanja bezbednosnih ciljeva za razliĉite potrebe

Analiza intervjua podrazumeva izradu kontrolnih upitnika za intervjue o

zaštiti informacija, u kojima se skupljaju, analiziraju i interpretiraju
rezultati razgovora (anketa). Prema iskustvu, upitnici mogu sadrţavati 7-
8 tema sa ukupno oko 20 pitanja. Intervjuisane organizacije moraju biti
raznovrsne (industrijske, drţavne). Rezultati se analiziraju korišćenjem
metoda interpretacije analize, a pokazuju inicijalnu sliku stvarne
situacije. Broj uzoraka merenja - izabranih entiteta za intervjue, treba biti
priliĉno velik da bi se rezultati mogli uopštavati. Oblasti za prikupljanje
informacija putem kontrolnog upitnika odnose se na kritične elemente
kontrola zaštite, a mogu obuhvatiti, [7]: upravljačke kontrole
(upravljanje rizikom, revizija kontrola zaštite, razvoj životnog ciklusa
sistema zaštite, sertifikacija i akreditacija, planiranje sistema zaštite),
operativne kontrole (personalna zaštita, fizička zaštita, kontrole

- 414 -
efektivnosti ulazno/izlaznih performansi, planiranje vanrednog dogaĎaja,
upravljanje konfiguracijom sistema, integritet podataka i sistema,
dokumentacija zaštite, svest o potrebi i obuka o zaštiti, upravljanje
kompjuterskim incidentom) i tehničke kontrole (identifikacija i
autentifikacija, logička kontrola pristupa, kontrola log datoteka
bezbednosnih dogaĎaja). Teme za razgovore mogu biti: okvir sistema
zaštite (organizacija, okruženje); bezbednosni ciljevi (iz programa i
politike zaštite); metrički sistemi u IKT sistemu; implementacija
metričkih sistema; osnove za metričke sisteme (standardi i druga
dokumentacija); upravljanje rizikom i kvalitetom zaštite; potreba za
metričkim sistemom zaštite (okvir, razvoj).

- 415 -
2. RAZVOJ PROGRAMA METRIĈKOG SISTEMA ZAŠTITE

2.1. Struktura programa metriĉkog sistema zaštite

Program metriĉkog sistema zaštite treba da ukljuĉi 4 interaktivne

komponente (Sl.2.1), [10]. Jaka podrška menadžmenta kritiĉna je
komponenta za uspeh programa zaštite i implementaciju programa
metriĉkog sistema zaštite. Praktične politike i procedure zaštite,
neophodne su za nametanje usaglašenosti, ako ih podrţavaju menadţeri.
Metrika se ne moţe lako izvesti, ako nema implementiranih procedura.
Kvantitativna metrike performansi sistema zaštite, dizajnira se da
obezbedi relevantne podatke o izvršavanju ciljeva zaštite. Rezultatski
orijentisana metrička analiza, bazirana na izvršavanju ciljeva zaštite,
lako dostupna i izvodljiva za merenje, ponovljiva i pogodna za praćenje
performansi i usmeravanje resursa zaštite.

Rezultatski orijentisana
metrička analiza

Kvantitativna metrika performansi

Praksa zaštite,
politike i procedure

Jaka podrška menadţmenta

Sl. 2.1. Struktura programa metriĉkog sistema IKT zaštite

Uspeh implementacije programa zaštite procenjuje se u odnosu na stepen

proizvodnje relevantnih rezultata, pa program zaštite treba da definiše,
[1]: uloge i odgovornosti za program sistema kvaliteta zaštite; metriĉki
sistem(e) zaštite, uputstva za merenja sa prednostima i nedostatcima i
faktorima uspeha programa svakog sistema merenja; metode i procese
koji se koriste u razvoju svakog metriĉkog sistema; faktore uticaja na
implementaciju i implementira program metrike i istakne znaĉaj
periodiĉne analize mernih podataka za: obuku, poboljšanje efektivnosti
procesa zaštite i planiranje kontrola zaštite.

- 416 -
2.2. Izbor tipa metriĉkog sistema

Zrelost programa zaštite odreĊuje tipove metriĉkih sistema koji se

uspešno mogu razviti i primeniti. Zreo program zaštite normalno
implementira brojne mehanizme za praćenje, dokumentovanje i
kvantitativnu verifikaciju razliĉitih aspekata performansi sistema zaštite.
Što je više podataka na raspolaganju, to je merenje lakše, a raste i
mogućnost automatizacije skupljanja podataka za kvantitativno merenje,
u zavisnosti od povećanja broja podataka iz automatizovanih izvora u
odnosu na humane izvore. Manuelno skupljanje podataka zahteva izradu
upitnika i voĊenje intervjua i anketa u organizaciji. Korisniji podaci se
dobiju od automatizovanih alata za procenu sistema zaštite, tehnika i
alata za sertifikaciju baza podataka o kompjuterskim incidentima i
izveštajima i drugim izvorima, kao što su rezultati primene SSE CMM
modela za merenje zrelosti programa i procesa zaštite.

Izbor tipa metriĉkog sistema koji se realno moţe koristiti za poboljšanje

performansi sistema zaštite, zavisi od zrelosti implementacije kontrola
zaštite, [6], [7], [10]:

1. Tip (3. nivo zrelosti): procenat sistema (n.p.r. radnih stanica/servera u

LAN) sa odobrenim planovima zaštite; procenat sistema (n.p.r. radnih
stanica/servera u LAN) sa politikama pasvorda i pravima pristupa
konfigurisanim u skladu sa bezbednosnim zahtevima u politici zaštite.
Kako se sistem progresivno razvija od 1. i 2. nivoa, rezultati ovih
merenja moraju biti manji od 100%, što indicira da sistem još nije
dostigao 3. nivo zrelosti. Kada merenje implementacije dostigne i ostane
100%, smatra se da su kontrole zaštite potpuno implementirane i da je
sistem zaštite dostigao 3. nivo zrelosti.

2. Tip (4. i 5. nivo zrelosti): kada se program zaštite organizacije razvije

i podaci o performansama postanu dostupniji, metriĉki sistem se fokusira
na merenje efikasnosti– blagovremenosti isporuka servisa zaštite i
efektivnosti sistema zaštite – operativnih rezultata performansi
implementiranih kontrola zaštite. Ova metrika je alat za validaciju
(sertifikaciju) efektivnosti kontrola zaštite, opisanih u planu zaštite, u
pogledu zaštite objekata IKT sistema. Na primer, proraĉunom procenta
pasvorda koji se mogu krekovati u predefinisanom vremenskom periodu,
merenjem duţine vremena potrebnog za krekovanje pasvorda usaglašenih

- 417 -
sa politikom organizacije, vrši se validacija efektivnosti politike zaštite
pasvordom u IKT sistemu organizacije.

3. Tip (5. nivo zrelosti): kada su jednom kontrole zaštite integrisane u

procese organizacije, procesi postaju samo-regenerativni, a skupljanje
mernih podataka potpuno automatizovano, moţe se meriti uticaj
bezbednosno relevantnih dogaĊaja na poslove i misiju organizacije,
analizom korelacije podataka. Na primer, merenje uticaja obuke na
sistem zaštite, podrazumeva kvantifikovanje incidenata po tipu (npr.
kompromitacije ruta, kompromitacije pasvorda, malicioznog kôda, DoS
napada) i korelaciju dobijenih podataka sa procentom obuĉenih korisnika
i administratora sistema.

2.3. Proces razvoja i implementacije programa metrike zaštite

Razvoj i implementacija programa metrike zaštite odvija se kroz

dva procesa: razvoj metričkog sistema i implementacija programa
metrike zaštite, [8], [10].

1. Razvoj metričkog sistema obuhvata inicijalni skup metrika i selekciju

odgovarajućeg podskupa, a odvija se kroz dve faze: identifikacija i
definisanje tekućeg programa zaštite (prva 4 koraka) i razvoj i izbor tipa
metričkog sistema kontrola zaštite, koji zavisi od nivoa zrelosti procesa u
ţivotnom ciklusu (preostala 3 koraka), ukljuĉujući razvoj sva tri tipa
metriĉkog sistema. Uĉestanost skupljanja rezultata svake metrike zavisi
od ţivotnog ciklusa samog dogaĊaja merenja, na primer: merenje
procenta kompletiranih ili aţuriranih planova zaštite, treba vršiti
najmanje 1 put u 6 meseci, a merenje pasvorda koji se mogu krekovati
treba vršiti najmanje 1 put meseĉno.

2. Implementacija programa metrike zaštite je iterativna

operacionalizacija programa metrike kroz 6 koraka, koji kada se potpuno
izvrše, obezbeĊuju neprekidnost korišćenja metrike zaštite za
monitorisanje i poboljšanje performansi kontrola zaštite i obezbeĊivanje
merenja odgovarajućeg aspekta sistema IKT zaštite. Iterativna priroda
ciklusa obezbeĊuje monitorisanje progresa i planiranog uticaja
korektivnih akcija na implementaciju kontrola zaštite. Ako korektivne
akcije nisu implementirane, ili planirane, ili daju neoĉekivan efekat,
ĉešće merenje performansi obezbeĊuje brzu, internu korekciju, ĉime se

- 418 -
smanjuju problemi koji se mogu otkriti u procesima auditinga i
sertifikacije.

Na uspeh programa metrike zaštite utiĉu brojni faktori, a posebno stepen:

ukljuĉivanja specifiĉnosti organizacione strukture i upravljivosti procesa
i podataka u okviru prihvatljivih ograniĉenja resursa. Da bi se obezbedila
validnost mernih podataka, metodi za skupljanje i proces izveštavanja
treba da budu standardizovani. Validnost mernih podataka je ugroţena,
ako se skupljaju iz baze koju pogaĊaju incidenti. Naĉini skupljanja
mernih podataka i izveštavanje o rezultatima merenja, moraju biti jasno
definisani u programu za razvoj i implementaciju metrike zaštite. U
PRILOGU II 9B prikazan je uzorak (NIST) standardne forme
dokumenta za opis metriĉkog sistema zaštite, [11]. U PRILOGU II P9C
prikazan je primer primene metrike na dva kritiĉna elementa Plana
zaštite.

Program metrike zaštite je od posebnog znaĉaja za procese digitalne

forenzike: istragu i prikupljanje digitalnih dokaza, formiranje neoborivog
dokaza, dokazivanje i sudsko veštaĉenje, jer obezbeĊuje ponovljivost
testiranja i merenja digitalnih dokaza po zahtevu pravosudnih organa, što
je jedan od kljuĉnih standardnih kriterijuma za priznavanje posrednog
digitalnog dokaza pred sudom.

U cilju boljeg razumevanja procesa razvoja programa i implementacije

metriĉkog sistema zaštite, kao i sticanja veštine za izradu dokumenata
Politika metrike zaštite i Implementacija metričkog sistema zaštite,
razvijena je VEŢBA GII 9.

- 419 -
3. PREDNOSTI I NEDOSTACI METRIĈKIH SISTEMA ZAŠTITE

Prednosti korišćenja metriĉkog sistema zaštite za organizaciju su

brojne: poboljšanje kontrolisane odgovornosti (accountability),
ukazivanjem na specifiĉne kontrole koje nisu implementirane ili su
nekorektno implementirane; merenje svakog aspekta sistema zaštite,
kvantifikovanjem i korišćenjem razliĉitih rezultata (analize rizika,
testiranja sistema zaštite na proboj, bezbednosnog testiranja i evaluacije
sistema zaštite i aktivnosti u zaštiti); izolovanje problema u zaštiti, na
bazi mernih podatke za procenu, opravdanje i usmeravanje investicija na
oblast zaštite koju treba poboljšati; usklaĊivanje sa zakonima i
regulativama i angaţovanje na proaktivnoj zaštiti; opravdanje
investiranja u zaštitu, na bazi kvantitativnih mernih podataka; merenje
efektivnosti implementiranih kontrola procesa/procedura zaštite i.t.d.

Nedostaci metriĉkih sistema su poznati. Glavni problem, svakako je

merenje uticaja ljudskog faktora na sistem zaštite. Neke organizacije ga
prevazilaze angaţovanjem nezavisnih eksperata, pa nemaju potrebu za
merenjem uticaja ljudskog faktora. Uzroci slabe ili neadekvatne
implementacije metriĉkih sistema, generalno nastaju najĉešće zbog
nedostatka ili nepostojanja: jasno definisanih procesa metriĉkih sistema;
svesti o potrebi kvalitetnog upravljanjem zaštitom informacija;
spremnosti menadţerske strukture za angaţovanje u oblasti zaštite;
dokumenata zaštite (Uputstvo za metriku zaštite); odgovornosti za sistem
zaštite i brojnih tehniĉkih rešenja metriĉkih sistema zaštite, [10].

- 420 -
4. REZIME

Metriĉki sistemi zaštite imaju brojne aplikacije, od monitoringa

do procesa analize. Ne postoje široko prihvaćeni i korišćeni standardi za
merenje zaštićenosti informacija i informacionih (digitalnih) objekata
IKT sistema. U oblasti zaštite metriĉki sistemi daju najbolje rezultate
kada se primenjuju kao proces, planiran u pripremnoj fazi razvoja
sistema zaštite. Sa aspekta sistema kvaliteta programa zaštite, od
presudnog znaĉaja je razviti, uspostaviti i implementirati na nivou
organizacije program metrike zaštite, razviti metriĉki sistem zaštite,
definisati proces implementacije i model cikliĉne evaluacije procesa
zaštite (SSE-CMM), umesto manje-više sluĉajnog izvršavanja procesa
zaštite.

Proces razvoja metriĉkog sistema odvija se u dve faze (7 koraka), a

proces implementacije metriĉkog sistema kroz 6 iterativnih koraka, koji
kada se potpuno izvrše, obezbeĊuju neprekidnost korišćenja metrike
zaštite za monitorisanje i poboljšanje performansi kontrola zaštite i
merenja odgovarajućeg aspekta sistema IKT zaštite.

Metrika zaštite je od posebnog znaĉaja za procese digitalne forenzike:

istragu i prikupljanje digitalnih dokaza (forenzičku akviziciju),
dokazivanja (forenzička analiza)i sudsko veštaĉenje, pošto obezbeĊuje
ponovljivost testiranja i merenja digitalnih dokaza po zahtevu
pravosudnih organa, što je jedan od kljuĉnih standardnih kriterijuma za
priznavanje posrednog digitalnog dokaza pred sudom.

- 421 -
5. KLJUĈNE REĈI

Merenje: jednokratni uvid u specifiĉne merne parametre

komponente/sistema zaštite.
Metrika: višekratno merenje u duţem vremenskom periodu ili sredstvo
za interpretaciju agregiranih podataka merenja (mernih podataka) na
višem nivou (n.p.r., organizacije).
Metriĉki sistem: skup kriterijuma, parametara, mernih podataka i
jedinica za izraţavanje rezultata merenja, koji uobiĉajeno podrazumeva
procese evaluacije (auditing, analiza ranjivosti, testiranje na proboj) i/ili
monitoringa performansi servisa zaštite (tehniĉki sistem metrike, log
datoteke).

- 422 -
6. LITERATURA

1. Bate R., and all, A Systems Engineering Capability Maturity

Model V.1.1, Software Engineering Institute, US DoD, 1995.
2. Grance T., &all, Guide to Information Technology Security
Services, NIST SP 800 35,
http://csrc.nist.gov/publications/nistpubs/800-35/sp800-35.pdf,,
2003.
3. Grance T., Hash J., Stevens M., Security Considerations in the
Information System Development Life Cycle , NIST SP 800-64,
http://csrc.nist.gov/publications/nistpubs/800-64/sp800-64.pdf,
juni 2004.
4. Jeffrey R. W., Karen M. F., P3I – Protection Profile Process
Improvement, Arca Systems, Inc., william@arca.com,
ferraiolo@arca.com, 2004.
5. Pankaj Goyal, CS497 – Security engineering and software
engineering, Indian Institute of technology, Kanpur, India, e-mail:
[pankajgo]@cse.iitk.ac.in, 2005.
6. Petrović R.S., Ĉekerevac Z., Grubor G., Security System
Engineering Capability Maturity Model in The ICT Security, 10.
meĊunarodna nauĉna konferencija ―Rešavanje kriznih situacija u
specifiĉnim prostorima‖, Fakultet specijalnog inţenjerstva, ŢU,
Ţilina, Slovaĉka, 2005.
7. Ross R., Katzke S., NIST SP 800-53, A, B, C, Recommended
Security Controls for Federal IS,
http://csrc.nist.gov/publications/nistpubs/800-53/sp800-53.pdf,
2005.
8. Savola Reijo, Measurement of Security in Processes and
Products, www.vitt.ele, 7.04.2005.
9. Stoneburner G., Hayden C. and Feringa A., Engineering
Principles for Information Technology Security (A Baseline for
Achieving Security), NIST SP 800-27,
http://csrc.nist.gov/publications/nistpubs/800-27/sp800-27.pdf,,
2004.
10. Swanson M., & all, Security Metrics Guide for Information
Technology Systems, NIST SP 800-55,
http://csrc.nist.gov/publications/nistpubs/800-55/sp800-55.pdf,,
2003.
11. Swanson M., Security Self-Assessment Guide for Information
Technology Systems, NIST SP 800-26,

- 423 -
http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf,
2001.

- 424 -
 III GLAVA
UPRAVLJANJE ZAŠTITOM INFORAMACIONIH
SISTEMA

- 425 -
1. UPRAVLJANJE ZAŠTITOM INFORMACIJA

0. UVOD

Po završetku ovog poglavlja razumećete:

- metodologiju (principe, odgovornost,.) upravljanja zaštitom

- proces integralnog upravljanja IS i sistemom zaštite
- upravljačke kontrole najbolje prakse zaštite (ISO/IEC 17799)
- metrički sistem za evaluaciju upravljanja zaštitom
- preporuke za upravljanje zaštitom (ISO/IEC 17799)
- otvorene probleme u oblasti upravljanja zaštitom

Znaĉaj upravljanja zaštitom raste sa porastom obima e-

poslovanja, a time i kritiĉnosti procesa zaštite IS i legalne odgovornosti
menadţera za neadekvatnu zaštitu od malicioznih napada i zloupotreba.
Proces upravljanja sistemom zaštite obuhvata sveukupnu infrastrukturu
upravljaĉkih, operativno-organizacionih (proceduralnih) i tehniĉkih
kontrola zaštite u kojima je ĉovek faktor odluĉivanja.

Proces upravljanja zaštitom ne moţe se ograniĉiti na upravljanje

pristupom sistemu, ili upravljanje tehniĉkom infrastrukturom sistema
zaštite informacija. Upravljanje zaštitom mora obuhvatiti organizacione i
operativne aktivnosti izvan centra IS, za oporavak sistema posle
katastrofe (vanrednog dogaĊaja, incidenta), kao i metriku za potvrdu
efektivnosti procesa upravljanja. Aktivnosti odrţavanja sistema zaštite
informacija naziva se upravljanje zaštitom informacija – ISM
(Information Security Managament), prema kljuĉnom standardu za
upravljanje sistemom zaštite ISO/IEC 17799 u IS organizacija svake
veliĉine i tipa. Osnovni mehanizam upravljanja je politika zaštite. Klasa
upravljaĉkih kontrola zaštite u standardu najbolje prakse zaštite (ISO/IEC
17799) obuhvata sledeće relevantne familije kontrola zaštite: Procena
rizika, Planiranje zaštite, Akvizicija sistema i servisa, Evaluacija
kontrola zaštite, Sertifikaciju i akreditaciju sistema zaštite, koje u
kontekstu upravljanja zaštitom obavezno treba razmatrati. Skup
aktivnosti za odrţavanje i oporavak sistema posle katastrofe naziva se
upravljanje kontinuitetom poslovanja – BCM (Business Continuity
Managament), koja se uobiĉajeno tretira jedinstveno sa planiranjem
vanrednih dogaĊaja. U procesima ISM i BCM od posebnog znaĉaja je
odreĊivanje uloga i odgovornosti za izvršavanje i kontrolu procesa.

- 426 -
Upravljanje zaštitom informacija u suštini je upravljanje rizikom u IKT
okruţenju. Iako je ova identiĉnost priliĉno oĉigledna i intuitivno
prihvatljiva, nije sasvim taĉna. Naime, razvijene su brojne tehnike i
metode za upravljanje rizikom u IKT okruţenju, dok se komparativno
slabija paţnja posvećuje upravljaĉkom aspektu procesa zaštite u celini.
Posledica je da menadţeri, proseĉni korisnici i ne-specijalisti zaštite vide
zaštitu informacija kao tešku i komplikovanu oblast sa nerazumljivom
terminologijom.

Upravljanje zaštitom (programom i sistemom zaštite) generalno obuhvata

tehnike upravljanja brojnim upravljaĉkim, organizaciono-operativnim i
tehniĉkim komponentama zaštite. Upravljanje zaštitom na nivou
raĉunarskog sistema (RS) i mreţe (RM) obezbeĊuju procedure zaštite
ugraĊene u rutinske raĉunarske i mreţne operacije za odrţavanje
integriteta, poverljivosti i raspoloţivosti informacija i servisa. Specifiĉne
aktivnosti u koje se ugraĊuju procedure upravljanja zaštitom ukljuĉuju:
procena rizika; logovanje bezbednosnih dogaĊaja u procesu upravljanja
kompjuterskim incidentom; antivirusnu zaštitu; detekciju upada u mreţu,
procenu ranjivosti i odgovor na incidente; fiziĉku i zaštitu okruţenja IS i
fiziĉkih medija; kontrolu pristupa za administratore i korisnike; razvoj i
odrţavanje sistema; personalnu zaštitu i obuku; upravljanje vanrednim
dogaĊajem i nadzor i kontrolu usaglašenosti prakse zaštite sa politikom
zaštite.

Tehnike upravljanja programom, sistemom i komponentama sistema

zaštite brojne su i obuhvataju sve kategorije upravljanja: manuelnog (npr.
planiranjem), poluautomatskog (npr. CRAMM metod za upravljanje
rizikom) i automatskog (npr. EUA paketi za automatsku implementaciju
ovlašćenja pristupa u velikim sistemima i sl.).

U oblasti upravljanja zaštitom, brojni su otvoreni problemi i oĉekuje se

dalji razvoj.

- 427 -
1. METODOLOGIJA UPRAVLJANJA ZAŠTITOM

1.1. Principi upravljanja zaštitom

Opšte prihvaćeni principi zaštite (GAISP, v. G. I, p. 4) osnovni je

skup konzistentnih principa za upravljanje zaštitom, [4]. Namenjeni su
menadţerima u poslovnom sistemu, za razvoj svesti o potrebi zaštite i
osposobljavanje za efektivnije upravljanje zaštitom.

Kako je upravljanje rizikom najbliţa aproksimacija upravljanja zaštitom,

za razvoj procesa upravljanja zaštitom moţe se koristiti skup od pet
principa upravljanja rizikom:

1. Procena rizika i odreĊivanje bezbednosnih zahteva;

2. Uspostavljanje sistema za centralno upravljanje rizikom;
3. Implementacija rentabilnih politika i kontrola zaštite;
4. Promovisanje svesti o potrebi i obuka;
5. Nadzor i kontrola sistema zaštite i evaluacija efektivnosti i
usklaĊenosti.

Ovi se principi implementiraju sa ukupno 16 osnovnih aktivnosti (v. G.

III, p.1.1). Svaka osnovna aktivnost opisana je sa specifiĉnim primerima
koji mogu pomoći poslovnim sistemima da povećaju efektivnost
programa zaštite.

- 428 -
1.2. Uloge i odgovornosti

U organizaciji procesa upravljanja zaštitom sve uloge i

odgovornosti definisane su i dodeljene svim uĉesnicima, od najvišeg
nivoa menadţmenta do nivoa pojedinaĉnih odgovornosti za servise i
mehanizme zaštite, [1]. Logiĉno lice odgovorno za ISM je imenovano
lice za zaštitu informacija organizacije (CIO-Corporate Information
Officer), ali je trend da se ovom poslu posveti puno radno vreme, kao što
je profil CISSO - (Corporate Information System Security Officer),
referent (sluţbenik) za sistem zaštite informacija organizacije, koji je
odgovoran za zaštitu informacija u celoj organizaciji i angaţovan je puno
radno vreme. Postoji tendencija za podizanje odgovornosti za upravljanje
zaštitom na viši nivo u vidu profesionalnog profila CIAO (Corporate
Information Assurance Officer), referent za bezbednost informacija, koji
je ovlašćen i za sertifikaciju sistema zaštite, [14].

Najznaĉajniji resurs na raspolaganju svakom menadţeru zaštite za

upravljanje zaštitom, svakako je tim dobro obuĉenih specijalista zaštite.
Tim za zaštitu treba da poseduje razliĉita i specifiĉna znanja, veštine i
iskustva relevantna za lokalnu sredinu i okruţenje. Najbolja praksa
zaštite potvrĊuje potrebu da svaki ĉlan tima neprekidno prati neophodna
znanja i veštine, da se adekvatno obuĉava i usavršava u skladu sa
zahtevima organizacije i liĉnim zahtevima. U ovoj oblasti apsolutno je
potrebno proaktivno delovanje, pošto je veoma teško definisati i izvršiti
strateški plan zaštite, ako su promene zaposlenih u IKT sistemu, posebno
tima zaštite, ĉeste. Samo jedinstven i dobro obuĉen tim garantuje
postizanje dugoroĉnih bezbednosnih (strateških) ciljeva. Pri tome vaţno
je praviti razliku izmeĊu veština koje su na raspolaganju na trţištu i
veština i iskustava specifiĉnih za datu organizaciju i okruţenje. Prve se
odnose na veštine i znanja koja obuhvataju opštu praksu zaštite,
poznavanje principa, metodologija, koncepata, modela, tehnologija i alata
zaštite, a stiĉu se uglavnom specijalizacijom na brojnim kursevima
zaštite, renomiranih sertifikacionih tela (tipa CISP- Certified Information
Security Professionals, SANS i dr.). Drugi tip znanja i veština, koje se
odnose se na specifiĉna iskustava steĉena radom u konkretnoj
organizaciji, poseduje mali broj ljudi i ova znanja i veštine najĉešće nisu
dokumentovani i dostupni širem krugu profesionalaca u zaštiti. Obe
kategorije znanja i veština u zaštiti podjednako su znaĉajne, s tim da je
specifiĉno obuĉene specijaliste zaštite ĉesto teţe pronaći, zaposliti i
zadrţati.

- 429 -
1.3. Implementacija principa zaštite u program i sistem zaštite

Poslovni sistem treba da implementira sistem IKT zaštite u skladu sa

GAISP principima. Za postizanje bezbednosnih ciljeva i implementaciju
principa zaštite, treba na odgovarajući naĉin uspostaviti zakonske,
administrativno-regulativne i druge mere, standarde prakse zaštite,
procedure i entitete za zaštitu IKT sistema. Gde ne postoje implementiran
sistem zaštite i komponente zaštite, moraju se ukljuĉiti najmanje sledeće
upravljaĉke kontrole [2]:

 razvoj politike zaštite,

 obuka i podizanje svesti o potrebi zaštite,
 nametanje obaveza i elementarna praktiĉna obuka u oblasti zaštite;
 razmena informacija o incidentima i
 definisanje i saradnja nosioca odgovornosti u oblasti zaštite.

Prvi pristup upravljanju sistemom zaštite odnosi se na odreĊeni broj

infrastrukturnih servisa koji obezbeĊuju normalni rad komponenti,
ureĊaja i samog sistema zaštite. Osnovni nedostatak ovog pristupa je što
kompleksnost savremenih IS i sistema zaštite dovodi do postepene
degradacije efektivnosti servisa IS i sistema zaštite, ako nema dobro
organizovanog upravljanja zaštitom i sinhronizovanog sa procesom
upravljanja IS.

Drugi pristup integralnog upravljanja IS i sistemom zaštite tretira

upravljanje sistemom zaštite kao integracioni faktor informacionih
servisa i servisa zaštite, gde mehanizmi zaštite obezbeĊuju visoku
raspoloţivost informacionih servisa, a integrisano upravljanje obezbeĊuje
normalno i usklaĊeno funkcionisanje pod kontrolom sistem
administratora.

- 430 -
1.4. Procesi upravljanja sistemom zaštite informacija

1.4.1. Generički proces upravljanja sistemom zaštite informacija (ISM)

Generički proces ISM u osnovi sadrţi ĉetiri koraka:

identifikovanje pretnji, procena rizika, uspostavljanje politike zaštite i
implementacija kontrola zaštite za ublažavanje rizika, (Sl. 1.1a). Druga
opcija za razvoj osnovnog mehanizma za upravljanje zaštitom na
strateškom nivou – konzistentne politike zaštite, je korišćenje
standardnog sistema identifikatora – BS (Benchmark System). Benĉmark
sistem zaštite informacija – ISBS (Information Security Benchmark
System) predstavlja preporuĉeni (drţave i industrija) nivo izvršavanja
politika zaštite u normalnim uslovima i daje garanciju da se implementira
dobar program zaštite. Usaglašenost sa ISBS obezbeĊuje garanciju da je
organizacija imala dobru procenu pretnji i rizika i da je implementirala
adekvatne kontrole zaštite za ublaţavanje faktora rizika, (Sl.1.1b), [14].

Identifikovanje pretnji Benčmark sistem

Procena rizika
Uspostavljanje politike
zaštite

Uspostavljanje politike
zaštite

Implementacija kontrola Implementacija

zaštite kontrola zaštite

a. b.

Sl. 1.1. Generiĉki proces ISM (a) i usaglašenosti sa BS (b)

- 431 -
1.4.2. Integralni proces upravljanja IKT i sistema zaštite

U integralnom procesu upravljanja IS i (pod)sistemom zaštite, a u

skladu sa standardom ITU X.700, proces upravljanja obuhvata, [2]:

- monitoring (nadzor) komponenti (pod)sistema upravljanja,

- kontrolu, tj. isporuku i realizaciju upravljaĉkih kontrola i
- koordinacija rada komponenti (pod)sistema upravljanja.

(Pod)sistem upravljanja treba da omogući administratoru da:

- planira i organizuje kontrolu i evidentira korišćenje servisa IKT

sistema;
- reaguje na izmenu zahteva;
- obezbedi predviĊeno ponašanje servisa IKT sistema i
- obezbedi zaštitu informacija.

Drugim reĉima, (pod)sistem upravljanje treba da raspolaţe dovoljno

bogatim funkcionalnostima, daje efektivne rezultate, da je dovoljno
fleksibilan i da ne utiĉe na informacije. U standardu ITU X.700 izdvaja
se pet funkcionalnih oblasti upravljanja IS:

1. upravljanje konfiguracijom (uspostavljanje parametara za

normalni rad, nabavka/odlaganje komponenti, skupljanje
informacija o stanju sistema, prijem izveštaja o bitnim izmenama
uslova rada, izmena konfiguracije sistema);
2. upravljanje otkazima (identifikovanje otkaza, izolacija otkaza,
uspostavljanje funkcionalnosti sistema);
3. upravljanje funkcionisanjem (skupljanje/analiza informacija,
procena efektivnosti u stacionarnim i nestacionarnim uslovima,
izmena reţima rada);
4. upravljanje zaštitom (razvoj, projektovanje, implementacija,
uklanjanje/izmena kontrola zaštite, distribucija informacija,
reagovanje na incidente);
5. upravljanje kontrolnim informacijama (konfigurisanje i analiza
login datoteka za registrovanje bezbednosno relevantnih
dogaĊaja).

- 432 -
U model upravljanja uvodi se pojam objekta upravljanja, kao skup
karakteristika komponenti sistema, relevantnih za upravljanje, kao što su:

- atributi objekta,
- dopuštene operacije,
- izveštavanje, koji objekat moţe generisati i kakav izveštaj i
- veza sa drugim objektima upravljanja.

U skladu sa preporukama (ITU X701), (pod)sistem upravljanja

distribuiranim IKT sistemom uspostavlja se u klijent-server arhitekturi.
Klijent je agent upravljanja (kao programski model objekta upravljanja),
koji izvršava aktivnosti upravljanja i izraĊuje izveštaje (pri postojanju
odreĊenih subjekata) o izmenama u procesu upravljanja. Sa svoje strane
server-menadţer daje agentu komande za upravljanje i prima izveštaje.

Hijerarhija menadţera i klijenata koji meĊusobno interaktivno deluju u

procesu upravljanja moţe imati nekoliko nivoa. U toj hijerarhiji nivoi
igraju dvostruku ulogu: u odnosu na elemente na višem nivou oni su
agenti, a prema niţem nivou – menadţeri. Logiĉki povezan sa
arhitekturom na više nivoa, to je koncept poverljivog (ili delegiranog)
upravljanja u kojem menadţer prelaznog nivoa moţe upravljati
objektima, korišćenjem protokola i standardnih sredstava. Obavezan
elemenat u bilo kojem broju nivoa arhitekture je upravljačka konzola.

Generiĉki proces upravljanja u IKT sistemu deli se na sledeće oblasti:

- informaciono (atributi, operacije i izveštaje o objektima

upravljanja);
- funkcionalno (upravljanje aktivnostima i neophodnim
informacijama);
- komunikaciono (obim upravljaĉkih informacija) i
- organizaciono (razbijanje na oblasti upravljanja).

Kljuĉnu ulogu u ovom modelu upravljanja igra objektno-orijentisan

model upravljačkih informacija (ITU X720) koji podrţava inkapsualciju
i nasleĎivanje. Dodatno se uvodi pojam paketa kao skup atributa,
operacija, izveštaja i odgovarajućeg ponašanja. Dobar opis objektno
orijentisanog pristupa i modelovanja dat je u literaturi, [16].

- 433 -
Konceptualno je vaţan pojam „proaktivnog― tj. preventivnog
upravljanja, koje se zasniva na predviĊanju ponašanja sistema na osnovu
tekućih podataka i prethodno prikupljenih informacija. Najprostiji primer
proaktivnog upravljanja je generisanje signala o mogućim problemima sa
ĉvrstim diskom, posle serije programski neutralisanih grešaka oĉitavanja/
upisivanja.

- 434 -
1.5. Upravljaĉke kontrole najbolje prakse zaštite

Glavna funkcija procesa upravljanja zaštitom je da izradi i

implementira koncept (strategiju) sistema IKT zaštite, [9]. Prema
standardu najbolje prakse zaštite (ISO/IEC 17799), glavni cilj
upravljaĉko-administrativnih mera zaštite je formiranje programa rada u
oblasti zaštite informacija, obezbeĊenje implementacije programa zaštite,
selekcija i izbor potrebnih resursa i kontrola zaštite.

U skladu sa standardom ISO/IEC 17799 upravljanje zaštitom je

obuhvaćeno klasom upravljačkih kontrola zaštite, koja obuhvata sledeće
familije kontrola zaštite: Procena rizika, Planiranje zaštite, Akvizicija
sistema i servisa, Evaluacija kontrola zaštite, Sertifikaciju i akreditaciju
sistema zaštite, [5].

Posle analize rizika i identifikovanja kontrola zaštite u pristupu odozgo-

na dole, treba izraditi i uvesti u upotrebu procedure za izvršavanje ovih
aktivnosti.

- Implementacija pristupa odozgo-na dole u prvom koraku razbija

svaki proces u procedure i aktivnosti koje se lakše prepoznaju i
izvršavaju. Za svaki upravljaĉki proces (klase i familije) treba
identifikovati ili izvršiti sledeće aktivnosti, [12]:
- Precizno uspostaviti uloge: definisanje vlasnika informacija/
sistema/aplikacija i kontrolisane odgovornosti (accountability)
svakom korisniku za svaki proces;
- Definisati dužnosti i odgovornosti: odreĊuje obim liĉnih i
pojedinaĉnih zadataka i odgovornosti svih uĉesnika u sistemu
zaštite;
- Identifikovati specifične zadatke: obezbeĊuje efektivno
obuhvatanje svih kontrolisanih odgovornosti i prelazak na
sledeći korak;
- Definisanje standarda za kvalitet implementacije: ukljuĉuje
definisanje metodologije merenja parametara kvaliteta i
obezbeĊuje sredstva za validaciju kvaliteta izvršavanja svakog
zadatka;
- Implementacija procesa merenja/validacija: obezbeĊuje
bezbednosnu garanciju da je svaki pojedinaĉni zadatak uspešno
izvršen.

- 435 -
Primer: primena procesa implementacije na primeru razvoja Politike
zaštite na nivou organizacije znaĉi sledeće:

- Precizno uspostaviti uloge: uspostaviti jednog vlasnika-

odgovornog za proces razvoja/odrţavanja politike zaštite;
- Definisati dužnosti i odgovornosti: koje mogu biti (1)
odrţavanje sveukupnog procesa politike zaštite, (2) nadgledanje
procesa kontrole/odobravanja politike zaštite; (3) adekvatno
upoznavanje zaposlenih sa sadrţajem politike zaštite.
- Identifikovanje specifičnih zadataka: (1) za odrţavanje
sveukupnog procesa politike - kreiranje spiska svih potrebnih
pojedinaĉnih politika i odreĊivanje odgovornih za svaku
politiku, (2) za nadgledanje procesa kontrole/ odobravanja
politike – identifikovanje i odreĊivanje odgovarajućih
menadţera za rad u supervizorskom telu, uspostavljanje procesa
kontrole/odobravanja i vremenskog plana kontrole izvršavanja
politike; (3) za adekvatno upoznavanje zaposlenih sa sadrţajem
politike – pripremiti obaveštenje o upoznavanju zaposlenih sa
politikom i postaviti ga na sva oglasna mesta.
- Definisanje standarda za kvalitet implementacije: u ovom
primeru standard kvaliteta je dokaz da je svaki pojedinaĉni
zadatak iz politike zaštite izvršen, na osnovu pre-definisanih
kriterijuma merenja uspešnosti realizacije;
- Implementacija procesa merenja/validacije: interni tim
organizacije za kontrolu (audit) izvrši nezavisnu procenu
celokupnog procesa politike zaštite.

- 436 -
1.6. Administracija zaštite u distribuiranom OSI sistemu

Administracija sistema zaštite u distribuiranom IS OSI modela,

ukljuĉuje raspodelu informacija neophodnih za rad servisa i mehanizama
zaštite, kao i prikupljanje informacija i analizu njihovog funkcionisanja.
Primer su distribucija kriptografskih kljuĉeva, analiza znaĉenja
parametara zaštite, konfigurisanje log datoteka i.t.d.

Konceptualna osnova administracije zaštite je baza informacija za

upravljanje zaštitom. Takva baza moţe da postoji kao jedinstveni ili
distribuirani repozitorijum, ali svaki od implementiranih sistema treba da
raspolaţe informacijama neophodnim za realizaciju izabrane politike
zaštite, [2] .

U skladu sa preporukama ITU X.800 zadaci administratora zaštite dele se

na tri oblasti administracije: IS u celini, servisa zaštite i mehanizama
zaštite.

Glavne aktivnosti administracije IS u celini su obezbeĊivanje aktuelnih

politika zaštite, saradnja sa drugim administratorima sistema, reagovanje
na incidente, kontrola (audit) i uspostavljanje bezbednosnog stanja.

Administracija servisa zaštite ukljuĉuje klasifikaciju i odreĊivanje

objekata zaštite, razradu pravila za izbor mehanizama zaštite za
realizaciju servisa zaštite i saradnju sa drugim administratorima za
usaglašavanje servisa zaštite.

Obaveze administratora mehanizama zaštite odreĊuju se na bazi skupa

implementiranih mehanizama zaštite. Tipiĉne aktivnosti su:

- upravljanje kljuĉem (generisanje i distribucija),

- upravljanje kriptozaštitom (uspostavljanje i sinhronizacija
kriptografskih parametara; administracija kriptografskih
mehanizama za digitalni potpis i zaštitu integriteta i
neporecivosti),
- administracija upravljanje pristupom (distribucija informacija –
lozinki, pravila o radu sa lozinkama, liste prava pristupa i.t.d.),

- 437 -
 - upravljanje autentifikacijom (distribucija informacija – lozinki,
kljuĉeva, tokena, smart kartica i.t.d.),
- upravljanje dopunom saobraćaja (razrada i podrška pravila,
izdavanje karakteristika dopune saobraćaja – frekvencije, obima,
i.t.d.),
- upravljanje rutiranjem saobraćaja (dodeljivanje poverljivih
kanala veze),
- upravljanje registrima (distribucija informacija o servisima za
registraciju, administriranje tih servisa).

Oĉigledno da administracija sistema zaštite u distribuiranim IS OSI

modela arhitekture ima mnogo specifiĉnosti u poreĊenju sa
centralizovanim sistemom.

1.7. Razvoj metrike za evaluaciju upravljanja sistemom zaštite

Za odreĊivanje efektivnosti i efikasnosti procesa upravljanja

zaštitom uvodi se metriĉki sistem performansi procesa upravljanja.
Kriterijumi za izbor metriĉkog sistema mogu biti brojni parametri:

- ne postoje incidenti koji izazivaju ozbiljne probleme,

- broj novih implementacija kasni zbog bezbednosnih razloga,
- broj kritiĉnih poslova koji se oslanjaju na IS sa planom za
kontinuitet poslovanja,
- broj kritiĉnih objekata infrastrukture IS sa automatskim
nadzorom,
- poboljšanje svesti zaposlenih o etiĉkim principima, principima
zaštite i izvršavanje duţnosti na etiĉki i bezbedan naĉin,
- potpuna usaglašenost, ili dopuštena odstupanja od bezbednosnih
zahteva,
- procenat razvijenih i dokumentovanih planova i politika zaštite,
- procenat planova i politika zaštite sa kojima su upoznati svi
zaposleni i uĉesnici u sistemu.

Kako standard ISO/IEC 17799 ne nudi nikakvu metriku, za merenje

performansi procesa upravljanja moţe se uspešno koristiti model
progresivnog sazrevanja procesa zaštite - SSE CMM, specifiĉno
primenjen na procese upravljanja zaštitom, [10].

- 438 -
Skala nivoa sazrevanja procesa upravljanja zaštitom prikazana je na Sl.
1.2.

Sl. 1.2. Skala rasta nivoa sazrevanja procesa upravljanja

Na Sl. 1.2. nivoi procesa upravljanja oznaĉeni su glavnim

karakteristikama:

0. nivo: Ne postoji — proces upravljanja zaštitom nije uopšte primenjen,

1. nivo: Inicijalni proces — procesi upravljanja su ad hoc i neregularni,
2. nivo: Ponovljiv — procesi upravljanja slede regularni obrazac i
ponovljivi su,
3. nivo: Definisan — procesi upravljanja su dokumentovani i upoznata je
organizacija,
4. nivo: Upravljan — procesi upravljanja su nadzirani i mereni i
5. nivo: Optimizovan —primenjuje se najbolja praksa upravljanja
zaštitom.

Detaljan opis karakteristika procesa upravljanja zaštitom u IS na svim

nivoima zrelosti dat je u PRILOGU III 1A.

Izlazni rezultati kvalitetnog procesa upravljanja zaštitom informacija

mogu se grupisati u ĉetiri osnovne oblasti:

1. Strategijsko usklaĎivanje:
- bezbednosni zahtevi definišu se u skladu sa poslovnim zahtevima
organizacije,
- rešenja sistema zaštite uklapaju se u procese organizacije,
- investiranje u zaštitu usklaĊeno sa strategijom razvoja i
prihvaćeno na bazi procene rizika.
2. Nove vrednosti (kvalitet):
- standardan set praksi zaštite, tj. usklaĊenost sa najboljom
praksom zaštite,
- propisno odreĊeni prioriteti i distribuirani napori na oblasti koje
imaju najveći uticaj i daju najveće poslovne rezultate.
- rešenja zaštite su primenjena u celoj organizaciji i prihvaćena,

- 439 -
 - kompletna rešenja koja pokrivaju organizaciju, procese i
tehnologiju,
- neprekidnost poboljšanja kulture zaštite.
3. Upravljanje rizikom:
- prihvaćen i usaglašen profil rizika,
- razumevanje o izloţenosti faktorima rizika,
- svest o prioritetu upravljanja rizikom.
4. Merenje performansi:
- definisan set metrika,
- proces merenja sa povratnom spregom za progresivno
poboljšanje,
- nezavisna bezbednosna garancija.

U pripremi i implementaciji procesa upravljanja zaštitom menadţerska

struktura mora rešiti brojna pitanja koja su data u PRILOGU III 1B.

Kako su procesi upravljanja zaštitom najmanje razvijeni, a da bi se stekla

predstava o potencijalnim pretnjama i verifikovala efektivnost kontrola
zaštite ove komponente (upravljanje zaštitom) od tipiĉnih potencijalnih
pretnji, razvijena je Vežba GIII P1A.

- 440 -
2. OTVORENI PROBLEMI UPRAVLJANJA ZAŠTITOM
INFORMACIJA

Osnovne prepreke i problemi spadaju u dve potencijalne kategorije:

dobijanje neophodne podrške menadžerske strukture za izvršavanje
strateškog plana i dobijanje neophodne podrške ostalih organizacionih
(ne IT) jedinica za realizaciju politike zaštite, [1], [2], [5], [6], [12].

U teoriji i praksi zaštite evidentirani su sledeći problemi:

1. U procesu evaluacije (bezbednosnog vrednovanja) objekata IKT

sistema objektivna evaluacija kompleksnih sistema sa velikom
infrastrukturom veliki je problem za upravljanje zaštitom, posebno:

– klasifikacija IKT objekata organizacije: odreĊivanje prioriteta

evaluacije,
– evaluacija podataka i procena ranjivosti sistema: nedostaju čvrsti
kriterijumi,
– kvalitativna procena: subjektivna i unosi faktor neodreĊenosti,
– kompleksnost infrastrukture IKT sistema i sistema zaštite: teorija
verovatnoće nije korektan pristup,
– uticaj para pretnja/ranjivost na privatnost i poverljivost:
nepotpuno definisanje i merenje,
– upravljanje privatnosti informacija: nedostaje standard najbolje
prakse (Code of Practice, ISO 17799P).

Perspektivni i obećavajući pristupi rešavanju nekih od navedenih

problema su primena:

– Teorije dokaza (Dempster-Shafer Theory of Evidence),

– Fuzzy Set Theory (membership functions, aggregations,
defizzification) i
– Fuzzy logic, za procenu ranjivosti (1996, De Ru Ellof, 200-2002
Smith, Eloff).

- 441 -
2. U proceni ranjivosti tekući problemi su:
1. Teškoće razumevanja stvarnog uticaja ranjivosti, a zbog toga i
rizika za IKT sisteme u realnom okruţenju. Na nivou
mreţe/servera postoji više raspoloţivih alata, koji tretiraju
ranjivosti na razliĉite naĉine, pa ĉak i nestandardno imenuju
ranjivosti i izloţenosti sistema;
2. Mnogo informacija iz procesa analize ranjivosti sistema i
preobilni izveštaji oteţavaju administratorima da upravljaju
rezultatima analize ranjivosti sistema;
3. Znaĉajno kašnjenje razvoja bezbednosnih popravki (zakrpa) i
korekcija ranjivosti oteţava blagovremenu primenu seta
zahtevanih korekcija za pomeranje sistema u stabilnije i
bezbednije stanje. Delimiĉno rešenje je koncept proaktivne
zaštite.
U ovoj oblasti potrebno je više istraţivanja, kao što je:
a. standardizacija alata za procenu ranjivosti sistema:

- Nmap,
- Nessus Security Scanner,
- ISS Internet Security Scanner,
- Symantec-NetRecon i.t.d.

b. UsklaĎenost standardizacionih tela za procenu ranjivosti:

- CIDF –Common Intrusion Detection Framework,

- IETF – International Engineering Task Force,
- IDWG – Intrusion Detection Working Group,
- CVE – Common Vulnerabilities and Exposures....
c. IzvoĎenje važnih projekata za procenu ranjivosti:

i. Common Vulnerabilities and Exposures (CVE) – lista

standardnih imena za javno poznate ranjivosti i druge izloţenosti
sistema, [3] i
ii. Open Source Security Testing Methodology Manual - Uputstvo
je najambiciozniji projekat za standardizaciju testiranja
bezbednosti na Internetu.

- 442 -
d. Usvajanje standardnog formata izveštaja o analizi ranjivosti – VARF
Standardni format izveštaja o analizi ranjivosti - VARF (Vulnerability
Assesment Report Format) je novi model standarda podataka, koji
definišu format podataka za razmenu informacija o analizi ranjivosti
sistema i olakšava interakciju izmeĊu procesa upravljanja rizikom [13].
Koncept VARFa sadrţi set XSLT transformacija koje transformišu
rezultate izlaza iz alata za analizu ranjivosti sa otvorenim izvornim
kodom u usaglašen VARF format izveštaja, koji omogućava dalje
procesiranje rezultata analize rizika.

3. U oblasti detekcije upada u sistem osnovni problemi su:

a. standardizacija interoperabilnosti:

- uvoĊenjem u praksu standardnog formata za izveštavanje sa

izlaza razliĉitih IDS,
- korelacijom distribuiranih IDS na brojnim web lokacijama i
administrativnim domenima sa jedinstvenim formatom
izveštavanja,
- omogućavanjem komunikacije izmeĊu razliĉitih komponenti
IDS,
- kombinovanjem izlaza iz razliĉitih IDS alata, što zahteva
posebne parsing alate koji treba da diferenciraju znaĉajne razlike
na niskom nivou pretnji.
-
b. usaglašavanje meĎunarodnih tela za standardizaciju detekcije upada
u sistem:

- CIDF (Common Intrusion Detection Framework),

- IETF (International Engineering Task Force),
- IDWG (Intrusion Detection Working Group) i dr.

c. Identifikovanje ograničenja sistema za detekciju upada

Šifrovan saobraćaj/infrastruktura telefonskih centrala i svičera:

– Zahteva implementaciju monitoring sistema integrisanog u hostu

(serveru),
– Teţi problem je monitorisanje više hostova simultano.

- 443 -
Povećana brzina i kompleksnost napada:

– IDS baziran na tehnologiji digitalnog potpisa ima problem sa

upravljanjem povećanim obimom sintetiĉkih upada,
– ako se za detekciju anomalija povećava osetljivost IDS, generiše
se veći broj laţnih pozitivnih alarma.
–
d. Identifikovanje tekućih problema sistema za detekciju upada
Teškoće razvoja tačne procene situacije:

– u porastu je obim podataka koje treba interpretirati,

– nedostaje kooperacija i konsolidacija heterogenih tipova IDS i
drugih bezbednosnih alata (skenera za analizu ranjivosti i.t.d.),
– analiza i korelacija izlaznih rezultata još uvek su otvorena pitanja.
Automatizacija odgovora i oporavak od napada:
– potreba za preciznom dijagnozom u realnom vremenu,
– adaptivno praćenje situacija koje mogu nastati usled napada.

4. U oblasti privatnosti u procesima analize ranjivosti i monitoringa

IDS problemi su:

– kako sanirati sirove podatke tako da se uklone liĉni podaci i

podaci o organizaciji,
– kompromis izmeĊu zahteva za privatnost i sposobnost IDS da
detektuje napade,
– deljenje podataka izvan zone poverenja tako da se odrţi
privatnost,
– neophodnost uvoĊenja analize ranjivosti sistema zaštite i
privatnosti (SPVA) sliĉno analizi ranjivosti/pretnje.

- 444 -
3. PREPORUKE ZA UPRAVLJANJE ZAŠTITOM

U skladu sa standardom ISO/IEC 17799 hijerarhija strateškog

planiranja odozgo-na dole identifikuje one komponente programa zaštite,
ĉijim se efektivnim upravljanjem ispunjavaju svi zahtevi zaštite. Standard
fokusira paţnju na sledećih 10 kategorija upravljanja zaštitom u
poslovnim sistemima, usvojenih u nacionalnim programima zaštite IKT
sistema brojnih zemalja (SAD, Kanade, Australije, Nemaĉke i dr.):

1. Dokument Politike zaštite: osigurava da je organizacija svesno i

eksplicitno pristupila zaštiti IKT sistema relevantnog za organizaciju i da
uprava podrţava politiku zaštite.
2. Alociranje odgovornosti za zaštitu: definiše lica i entitete odgovorne
za zaštitu.
3. Obrazovanje i obuka u oblasti zaštite: jedna je od najvaţnijih i
najefikasnijih mera zaštite za korisnike i menadţere poslovnih sistema.
4. Upravljanje bezbednosnim incidentom i izveštavanje: izveštavanje o
svakom incidentu treba biti pravovremeno i potpuno i praćeno sa
mišljenjem kako sanirati incident i kako se najbolje suprostaviti budućim
sliĉnim incidentima.
5. Kontrola malicioznih programa: mora biti adekvatna porastu pretnji
od malicioznih programa i napada.
6. Plan upravljanja vanrednim dogaĎajima i kontinuiteta poslovanja:
obezbeĊuje raspoloţivost objekata i resursa IKT sistema za oporavak
sistema sa jasnom odgovornošću i procesima za razvoj ovog plana.
7. Zaštita intelektualne svojine: zahteva se zbog zakonskih restrikcija.
8. Zaštita baza podataka: obavezna je jer sadrţe agregirane, arhivirane i
poverljive podatke i informacije.
9. Zaštita integriteta, raspoloživosti i poverljivosti/privatnosti podataka i
informacija: u skladu sa bezbednosnim zahtevima za zaštitu integriteta,
raspoloţivosti, poverljivosti i privatnosti informacija.
10. UsklaĎenost sa politikom zaštite: mora se razmatrati regularno u
procesima nadzora i kontrole i akreditacije i sertifikacije sistema zaštite.

- 445 -
4. REZIME

U funkcionalnom modelu procesa upravljanja zaštitom, sistemski

principi zaštite IKT sistema podrazumevaju obavezan okvir u koga se
ugraĊuju specifiĉni GAISP principi zaštite. Obuhvataju tri glavna
organizaciona i personalna rešenja, koja su iskustveno potvrĊena i
unapreĊuju opštu bezbednost IKT sistema: nikada sam, rotacije radnih
mesta, razdvajanje duţnosti, i implementacije principa upravljanja IKT
sistemom. Opšte prihvaćeni principi zaštite (GAISP) osnovni je skup
konzistentnih principa za upravljanje zaštitom.

Upravljanje sistemom zaštite odnosi se na odreĊeni broj infrastrukturnih

servisa koji obezbeĊuju normalni rad komponenti, ureĊaja i sistema
zaštite u celini. Kompleksnost savremenih IS i sistema zaštite dovodi do
postepene degradacije efektivnosti servisa IS i sistema zaštite, ako nema
dobro organizovanog upravljanja.

U organizaciji procesa upravljanja zaštitom znaĉajno je odrediti uloge i

odgovornosti svih uĉesnika, od najvišeg nivoa menadţmenta do nivoa
pojedinaĉnih odgovornosti za servise i mehanizme zaštite. Najznaĉajniji
resurs na raspolaganju svakom menadţeru zaštite za upravljanje zaštitom,
svakako je tim dobro obuĉenih specijalista zaštite.

Pristup integralnog upravljanja IS i sistemom zaštite tretira upravljanje

sistemom zaštite kao integracioni faktor informacionih servisa i servisa
zaštite, gde mehanizmi zaštite obezbeĊuju visoku raspoloţivost
informacionih servisa, a integrisano upravljanje obezbeĊuje normalno i
usklaĊeno funkcionisanje pod kontrolom sistem administratora.

Integralni proces upravljanja IS i sistemom zaštite (standard ITU X.700)

obuhvata: monitoring (nadzor) komponenti (pod)sistema upravljanja,
kontrolu, tj. isporuku i realizaciju upravljaĉkih kontrola i koordinacija
rada komponenti (pod)sistema upravljanja.

Dobar pristup/metodologiju za uspostavljanje procesa za upravljanje

zaštitom obezbeĊuje standard najbolje prakse zaštite IEC/ISO 17799 sa
preporuĉenim kontrolama zaštite. Prema standardu najbolje prakse zaštite
(ISO/IEC 17799), glavni cilj upravljaĉko-administrativnih mera zaštite je
formiranje programa rada u oblasti zaštite informacija, obezbeĊenje
implementacije programa zaštite, selekcija i izbor potrebnih resursa i

- 446 -
kontrola zaštite. Osnovna komponenta programa zaštite je politika zaštite
na bazi analize rizika, koja odraţava pristup organizacije zaštiti svojih
informacija. Kada organizacija identifikuje oblasti procesa za upravljanje
zaštitom koje treba ukljuĉiti u program zaštite, treba da dekomponuje
aktivnosti (odozgo-prema-dole) u merljive i upravljive zadatke i
verifikuje uspešnost kompletiranja svakog zadatka

U skladu sa preporukama (ITU X.800) zadaci administratora zaštite dele

se na tri oblasti administracije: IS u celini, servisa zaštite i mehanizama
zaštite.

Za merenje performansi procesa upravljanja moţe se uspešno koristiti

metrika modela progresivnog sazrevanja procesa zaštite - SSE CMM,
specifiĉno primenjenog na procese upravljanja zaštitom. Koristi se skala
od 5 nivoa sazrevanja procesa upravljanja zaštitom: 0-ne postoji, 1-
inicijalni proces, 2-ponovljiv, 3-definisan, 4-upravljan, 5- optimizovan.

Osnovne prepreke i problemi u procesu upravljanja zaštitom su dobijanje

neophodne podrške menadţerske strukture za izvršavanje strateškog
plana i neophodne podrške ostalih organizacionih (ne IT) jedinica za
realizaciju politike zaštite. Brojni su problemi standardizacije tehnika
upravljanja, izveštavanja i usklaĊivanja standardizacionih tela za procese
evaluacije zaštite, procene ranjivosti, izlaza IDS sistema i dr.

- 447 -
5. KLJUĈNI TERMINI

Administracija IS i (pod)sistema zaštite: administracija integralnog IKT

sistema i podsistema zaštite, koja obezbeĊuje realizaciju aktuelnih
politika zaštite, saradnju sa drugim administratorima sistema, reagovanje
na incidente, kontrolu (audit) i uspostavljanje bezbednosnog stanja
sistema.
Administracija mehanizama zaštite: odreĊuju se na bazi skupa
implementiranih mehanizama zaštite i obuhvata brojne aktivnosti, koje
opisuju procedure.
Administracija servisa zaštite: klasifikacija i odreĊivanje objekata
zaštite, razrada pravila za izbor mehanizama zaštite za realizaciju servisa
zaštite i saradnja sa drugim administratorima za usaglašavanje servisa
zaštite.
Administracija zaštite u distribuiranom IS OSI modela: ukljuĉuje
raspodelu informacija neophodnih za rad servisa i mehanizama zaštite,
kao i prikupljanje informacija i analizu njihovog funkcionisanja.
Upravljanje sistemom zaštite: odreĊeni broj infrastrukturnih servisa koji
obezbeĊuju normalni rad komponenti, ureĊaja i sistema zaštite u celini
VARF (Vulnerability Assesment Report Format): standardni format
izveštaja o analizi ranjivosti, novi model standarda podataka, koji
definišu format podataka za razmenu informacija o analizi ranjivosti i
olakšava interakciju procesa upravljanja rizikom.

- 448 -
6. LITERATURA:

1. American Institute of Certified Public Accountants/Canadian

Institute of Chartered Accountants, SysTrust Principles and
Criteria for Systems Reliability V2.0, 2001
2. Domarev V.V.,Защита информации и безопасность
компьютерных систем, 1997.
3. Dr. Rayford B. Vaughn, Jr, A practical approach to sufficient
INFOSEC, Mississippi State University, Department of
Computer Science, vaughn@cs.msstate.edu, 2002.
4. GAISP –Generally Accepted Information Security Principles,
www.gaisp.org, 2003.
5. IEC/ISO 17799 Security Standard overview,
http://www.securityauditor.net/iso17799/what.htm, 2005.
6. International Federation of Accountants, Managing Security of
Information, www.ifa.org, 1998.
7. ISO/IEC 17799:2000, Information Technology – Code of
practice for information security management,
http://www.iso.17799.org, 2003.
8. ISO/IEC 21827 (SSE CMM), System Security Engineering
Capability Maturity Model, http://www.iso.21827.org., 2000.
9. IT Baseline Protection Manual, http://www.bsi.bund.de/gshb,
juli 2000.
10. IT Governance Institute, COBIT (Control Objectives for
rd
Information and related Technology) 3 Edition, 2000,
www.ITgovernance.org, www.isaca.org.
11. Patrick J., Organizational Information Security From Scratch –
A Guarantee For Doing It Right, SANS Institute,
http://www.sans.org, 2000.
12. Purser S., A practical guide to managing information security,
Artech House, Boston, London, http://www.artechhouse.com,
2005.
13. SANS Institute, Information Security Policies & Best Practices,
http://www.sans.org, 2003.
14. Schell P.G., McLeod Jr. R., Management Information Systems,
9.izdanje, Pearson Prentice Hall, SAD, 2004.
15. US General Accounting Office, Information Security:
Computer Attacks at Department of Defense Pose Increasing
Risks, www.fas.org/irp/gao/aim96084.htm, 1996.

- 449 -
16. Wendy B., Moshel B., UML i Rational Rose 2002, Kompjuter
biblioteka, Beograd, 2005.

- 450 -
2. UPRAVLJANJE BEZBEDNOSNIM RIZIKOM U
INFORMACIONOM SISTEMU

0. UVOD

Kada završite ovo poglavlje moći ćete:

- primeniti opštu metodologiju upravljanja rizikom

- primeniti formalnu metodologiju procene/proračuna rizika
- koristiti opšti metod za procenu:
▪ vrednosti objekata IS – A; pretnji – T; ranjivosti – V
uticaja T na V; preostalog rizika - Rrp

Upravljanje rizikom u IKT, u suštini, obuhvata sveukupan proces

uspostavljanja i odrţavanja sistema zaštite IKT objekata. Analiza rizika,
kljuĉna komponenta upravljanja rizikom, je naĉin na koji se rizik
identifikuje i procenjuje, da bi se opravdali troškovi sistema zaštite. Cilj
analize rizika je da se obezbedi rentabilan i adekvatan sistem IKT zaštite,
koji odgovara realnim pretnjama. U praksi zaštite termin upravljanje
rizikom ĉesto se koristi jedinstveno i obuhvata upravljanje i analizu
rizika.

Rizik je funkcija verovatnoće da će dati agent pretnje (izvršilac napada)

iskoristiti odreĊenu ranjivost IKT sistema i izazvati negativne posledice
za sistem i organizaciju u celini. Postoje tri vrste rizika: inherentni, koji
postoji bez obzira na sistem zaštite; tekući, koji je prisutan i uzima u
obzir postojeći sistem zaštite i preostali, prihvatljivi rizik koji obuhvata
postojeći i projektovani sistem zaštite, a prihvata ga menadţment
organizacije. Nivo prihvatljivog rizika, koji je specifiĉan za svaku
organizaciju, zavisi od misije, internih standarda, vrednosti objekata,
kulture organizacije i volje upravne strukture da prihvati rizik. Na taj
naĉin, misija sistema zaštite postaje odrţavanje sistema zaštite na
prihvatljivom nivou rizika od pretnji koje ga ugroţavaju.

Proces analize rizika u IKT moţe se primenjivati u toku celokupnog

ţivotnog ciklusa IKT sistema za: procenu bezbednosnog okruţenja;
formulisanje strategije bezbednosti i zaštite; odreĊivanje prioriteta u
implementaciji komponenti sistema zaštite; procena i kontrola
usaglašenosti prakse sa standardima, politikom i procedurama zaštite;
kontrolu funkcionalnosti sistema zaštite; procenu rizika od

- 451 -
napada/grešaka/sluĉajnih dogaĊaja; procenu i izbor rentabilnih kontrola
zaštite; projektovanje i upotrebu efikasnog i bezbednog softvera;
odreĊivanje i upotreba efikasne procedure za sistem zaštite, i odreĊivanje
odgovornosti za bezbednost i zaštitu IKT sistema.

Metodologija analize i procene rizika obuhvata 9 koraka: identifikacija i

procena vrednosti objekata-A, ranjivosti objekata-V, pretnji-T
(intenziteta, frekvencije i verovatnoće dogaĊanja), uticaja–Ut (pretnji na
iskoristive ranjivosti sistema i poslove organizacije) i procena faktora
rizika-R, kombinovanjem atributa A, T i V.

Proces upravljanja rizikom je kritiĉna komponenta razvoja i upravljanja

programom zaštite zato što identifikuje najveći mogući broj ranjivosti
sistema, koji se uopšte moţe otkriti. Procena rizika jedan je od kljuĉnih
koraka u razvoju programa zaštite, a daje informacije o tome šta treba
štititi, koji nivo zaštite i po kojoj ceni treba implementirati i koji nivo
rizika prihvatiti.

Zavisno od namene procesa upravljanja rizikom, bezbednosne mere i

metode ublaţavanja rizika mogu se svrstati po efikasnosti u 7 sledećih
grupa: izbegavanje rizika, transfer rizika, redukcija pretnji, redukcija
ranjivosti sistema, redukcija uticaja pretnji, detekcija pretnji i oporavak
sistema. Neke mere je lakše i jeftinije uvesti u ranoj fazi ţivotnog ciklusa
sistema.

U praksi, kontrole zaštite biraju se na bazi kombinacije atributa A, V i T,

da bi se dostigao izbalansiran i komplementaran sistem zaštita, u kojem
su manje efikasne kontrole zaštite dopunjuju sa efikasnijim, a tehniĉke
kontrole zaštite praćene sa upravljaĉkim i operativnim (proceduralnim) i
zajedno obezbeĊuju oĉekivanu efikasnost sistema zaštite.

- 452 -
1. OPŠTA METODOLOGIJA UPRAVLJANJA RIZIKOM

1.1. Glavni principi upravljanja rizikom u IKT sistemu

Rezultati istraţivanja iskustava iz prakse potvrĊuju da su IKT

sistemi poslovnih organizacija suoĉeni sa sliĉnim rizicima i koriste sliĉne
tehnologije za ublaţavanje rizika. Bezbednosni ciljevi su generiĉki za
gotovo sve poslovne sisteme u Internet okruţenju: zaštita integriteta,
poverljivosti i raspoloživosti podataka i informacija.

Generalno proces upravljanja rizika (UR) zasniva se na pet osnovnih

principa koji olakšavaju proces odreĊivanja rizika u dinamiĉki
promenljivom tehnološkom i fiziĉkom okruţenju:

6. Procena rizika i odreĊivanje bezbednosnih zahteva;

7. Uspostavljanje sistema za centralno upravljanje rizikom;
8. Implementacija rentabilnih politika i kontrola zaštite;
9. Promovisanje svesti o potrebi i obuka;
10. Nadzor i kontrola sistema zaštite i evaluacija efektivnosti i
usklaĊenosti.

Vaţan faktor za efektivnu implementaciju ovih principa je njihovo

povezivanje u ciklusu aktivnosti, koje obezbeĊuje da politike zaštite uvek
obuhvataju tekuće faktore rizika u realnom vremenu. Ciklus aktivnosti
upravljanja rizikom ilustrovan je na Sl.1.1, [15]:

PROCENA RIZIKA I
ODREĐIVANJE
POTREBA

IMPLEMENTACIJA
POLITIKA I NADZOR i
CENTRALNO
KONTROLA EVALUACIJA
UPRAVLJANJE
ZAŠTITE

PROMOVISANJE
SVESTI O POTREBI
I OBUKA U ZAŠTITI

Sl.1.1. Ciklus aktivnosti upravljanja rizikom

- 453 -
Ovakav ciklus aktivnosti upravljanja rizikom odrţava politike i kontrole
zaštite i nadzire rad sistema zaštite i istovremeno obezbeĊuje proces
upravljanja kontrolama zaštite u svakoj vrsti sistema/programa zaštite.

U standardu najbolje prakse zaštite razvijen je skup osnovnih aktivnosti

- BP (base practices) za implementaciju glavnih principa UR, iako se
zavisno od veliĉine i kulture organizacije mogu koristiti razliĉite tehnike.
Neki programi zaštite su po svojoj prirodi manje ili više zreli, odnosno
imaju manje ili veće kapacitete za zaštitu od drugih, ili nisu potpuno
implementirane sve osnovne aktivnosti. Da bi se postigla efektivnost
programa zaštite, većina eksperata za upravljanje sistemom zaštite
saglasna je da je kljuĉno implementirati 16 sledećih BP, koje se odnose
na pet glavnih principa UR (Tabela 1.1), [25].

- 454 -
Principi UR Osnovne aktivnosti (BP)

Prepoznavanje digitalnih objekata, kao

bitnih resursa organizacije

Razvoj praktične procedure za procenu

rizika, koja povezuje sistem zaštite sa
Procena rizika i odreĎivanje potreba poslovnim potrebama organizacije

OdreĎivanje odgovornosti organa uprave

za program zaštite

Neprekidno upravljanje rizikom

OdreĎivanje radnog tima za izvršavanje

ključnih aktivnosti

ObezbeĎivanje brzog i nezavisnog

pristupa centralnog radnog tima glavnim
izvršiocima odluka
Uspostavljanje sistema za centralno
upravljanje rizikom
ObezbeĎivanje potrebnog osoblja i
finansiranja

UnapreĎivanje tehničke obučenosti i

profesionalnog odnosa članova
centralnog radnog tima

Povezivanje politike zaštite sa faktorima

rizika

Implementacija odgovarajućih politika i Definisanje razlika izmeĎu politika i

kontrola zaštite uputstava (guidelines)

Podržavanje politike kroz rad centralnog

radnog tima za zaštitu

Neprekidna obuka korisnika i drugih

Promovisanje svesti o potrebi i obuka
učesnika o uticaju faktora rizika i
korisnika
odgovarajućim politikama

- 455 -
 Upotreba tehnika prikladnih za korisnike

Nadzor i kontrola faktora koji utiču na

rizik i indiciraju efektivnost zaštite

Korišćenje rezultata evaluacije za

Nadzor i kontrola efektivnosti sistema
usmeravanje sledećih aktivnosti i
zaštite i evaluacija usklaĎenosti politike i
uspostavljanje odgovornosti organa
prakse zaštite
uprave

Održavanje spremnosti za uvoĎenje novih

tehnika i alata za nadzor sistema zaštite

T. 1.1. Principi i osnovne aktivnosti upravljanja rizikom

OdreĊivanje prioriteta za implementaciju osnovnih aktivnosti varira od

organizacije do organizacije u zavisnosti od postojećeg programa zaštite.
U PRILOGU III 2A opisano je detaljno svih 16 osnovnih aktivnosti
(BP-Basic Practices) za upravljanje rizikom u IKT sistemu organizacije.

- 456 -
1.2. Opšti model analize rizika

Generalni sistemski prilaz modeliranju procesa analize faktora

rizika definiše sistem kao skup objekata, meĊusobnih relacija tih objekata
i njihovih atributa i relacija atributa objekata prema okruţenju. Generalna
teorija sistema vidi probleme sa široke holistiĉke perspektive u kojoj se
IS i okruţenje razmatraju kao jedna celina koju karakterišu sledeći
entiteti (Sl.1.2): ciljevi, okruţenje, resursi, komponente, upravljanje, [3],
[18].

Odnosi sistema i okruţenja i stepen kontrole koju neka organizacija moţe

izvršiti na faktore iz okruţenja sistema, zavise u najvećoj meri od obima i
intenziteta skupljanja informacija implicitnih analizi faktora rizika.
UPRAVLJANJE RIZIKOM

P R O C E N A (A N A L I Z A) R I Z I K A

Analiza:
-vrednosti Procena
Obim Test prihvatanja
objekata, (merenje)
preostalog rizika
- verovatnoće rizika
i intenziteta
pretnji,
-ranjivosti
objekata,
- uticaja
Akcija:
pretnji,
promena u
- sistema
okruţenju
zaštite
sistema

STEPEN NEODREĐENOSTI

Sl.1.2. Opšti model analize rizika, [18]

Opšti model analize rizika, prikazan na Sl. 1.2, sadrţi 3 konceptualne

oblasti: upravljanje rizikom, procena rizika i neodreĎenost koja
interaktivno deluje sa faktorima procene rizika.

Kao prvi stepen definiše se obim procene rizika. Zatim se analiziraju

komponente rizika: objekti, pretnje, ranjivost, uticaj, zaštita i
verovatnoća, da se kvantifikuju njihovi atributi i specificiraju meĊusobni
odnosi. Iz rezultata analize formiraju se mere faktora rizika. Ove mere se
propuštaju kroz test prihvatanja da se odredi da li odgovaraju realnosti.
Ako odgovaraju, proces ulazi u okvir menadţmenta rizika, gde se mogu

- 457 -
specificirati promene zahteva za sistem ili okruţenja sistema. Procedura
se ponavlja sve dok predloţeni rezultati ne zadovolje.

1.3. Zajedniĉke osnove procesa upravljanja rizikom

Proces upravljanja rizikom najbolje istiĉe gde su tehnološki kapaciteti

najpogodniji za ublaţavanje, redukciju ili eliminisanje rizika.
Ublaţavanje rizika od napada pomoću tehniĉkih sredstava moţe biti
efikasno u sledećim uslovima, [25]:
 Napad postoji: mera zaštite - implementirati pouzdane tehnike za
smanjenje verovatnoće neţeljenog napada;
 Napad je iskoristiv (postoji ranjivost): mera zaštite - primeniti
slojevitu zaštitu i projektovati arhitekturu sistema da se spreĉi
iskorišćenje ranjivosti;
 Troškovi napada su manji od dobiti za napadaĉa: mera zaštite -
primeniti zaštitu da se povećaju troškovi napada ili znaĉajno smanjiti
potencijalnu dobit napadaĉa, n.p.r. izborom ne-tehniĉkih mera kao što
je ograniĉavanje obima osetljivih procesiranih informacija;
 Gubitak je suviše velik: mera zaštite - primeniti principe
projektovanja, arhitekture, ne-tehniĉke i tehniĉke zaštite za
ograniĉenje nivoa napada, a time i smanjenje gubitaka, n.p.r. izborom
ne-tehniĉkih mera kao što je ograniĉavanje obima osetljivih
procesiranih informacija.
Na slici Sl.1.3. prikazan je tok procesa uspešnog odrţavanja rizika na
prihvatljivom nivou u sluĉaju tipiĉnog namernog, ali ne i malicioznog
napada sa Intraneta, [9].
Moguć
napad

DA DA Postoji
Analiza
sistema
Ranjivost
?
Iskoristiva
?
ranjivost za
napad
&
NE NE

Nema rizika Nema rizika

DA DA
Prihvatljiv
Napadača Neprihvatljiv
Postoji pretnja gubitak >
troškovi < rizik
dozvoljenog
dobiti

NE NE

Prihvatljiv Prihvatljiv
rizik rizik

- 458 -
Sl.1.3. Tok procesa upravljanja rizikom od nemalicioznog namernog
eksternog napada
U analizi uticaja faktora rizika razvija se scenario ―šta ako‖ u sluĉaju da
se dogodi svaki razmatrani faktor rizika. Procenjuju se frekvencija i
verovatnoća pojave i intenzitet uticaja svakog faktora rizika, kao i uticaja
kombinacije faktora rizika. Procena faktora rizika moţe biti valjana za
odreĊeno vreme i ako se temeljito uradi, ali se scenario pretnji brzo
menja pa se i procena mora sukcesivno aţurirati. Proces upravljanja
rizikom integriše se i podrţava sve faze ţivotnog ciklusa sistema sa
odreĊenim aktivnostima i izlaznim rezultatima (PRILOG III 2B).

- 459 -
1.4. Formalna metodologija procene rizika

Generalno, kod svih poznatih metoda za procenu rizika u prvoj

fazi potrebno je izvršiti bezbednosnu klasifikaciju i kategorizaciju
objekata IKT sistema i odrediti njihove vrednosti ili osetljivosti za
organizaciju. Metod bezbednosne klasifikacije i kategorizacije opisan je
u Glavi I, poglavlje 10, [5]. Sledeći korak je procena scenarija mogućih
izvora pretnji (internih, sluĉajnih, namernih, kombinovanih), kapaciteti
potencijalnih napadaĉa na IKT sistem (motivacija i sposobnosti) i naĉin
napada: silom, kraĊom, prevarom, diverzijom ili sluĉajnim upadom i
verovatnoće napada. Sledeća bitna analiza projektnog tima je simulacija
―kako bi korisnik sam probio svoj sistem zaštite‖. Zatim se procenjuju
ranjivosti objekata, odnosno atraktivnost objekata, izloţenost i vrednost
za napadaĉa. Dalje se procenjuje scenario potencijalno realizovanih
napada - incidenata i faktori njihovog rizika, gde se pretpostavlja da se
svaki napad moţe dogoditi i kada se moţe dogoditi. Zatim se
preporuĉuju kontrole zaštite za ublaţavanje tih faktora rizika na
prihvatljiv nivo i dokumentuju rezultati procene rizika.

Formalne metodologija procene rizika moţe se primeniti u procesu koji

obuhvata 9 primarnih koraka, [18], [23]:

Korak 1: Procena vrednosti (analiza sistema, klasifikacija i

kategorizacija);
Korak 2: Procena pretnji;
Korak 3: Procena ranjivosti;
Korak 4: Analiza kontrola sistema zaštite;
Korak 5: OdreĊivanje verovatnoće realizacije pretnji;
Korak 6: OdreĊivanje verovatnoće uticaja (pretnje na iskoristivu
ranjivost sistema);
Korak 7: Proraĉun (odreĊivanje, procena) rizika;
Korak 8: Preporuka kontrola zaštite za ublaţavanje rizika;
Korak 9: Dokumentovanje rezultata analize rizika.

U PRILOGU III 2C opisan je grafiĉki model toka procesa procene

rizika primenom formalne metodologije sa aktivnostima procesa, ulazima
i izlazima iz svakog koraka.

- 460 -
U odnosu na objekte primene, u praksi zaštite u upotrebi su najĉešće
ĉetiri opšta metoda primene procesa analize rizika, [11]:

1. Metod analize rizika procesa rada,

2. Metod analize rizika funkcionalnih celina,
3. Metod analize rizika kritičnih objekata i
4. Strukturni metod brze analize rizika (BAR).

Osnovne karakteristike opštih metoda analize rizika opisane su u

PRILOGU III 2D.
U svim metodima analize rizika, razlikuju se primarni i sekundarni
faktori rizika, [3]. Primarne faktore rizika odreĊuje maksimalna
osetljivost objekata i minimalna zaštita za date ranjivosti sistema.
Sekundarni faktori rizika dobiju se iz Izjave o osetljivosti (IoO) objekata
i analize faktora rizika. Izjava o osetljivosti sadrţi odgovore na skup
pitanja u upitniku koji se upućuje vlasnicima objekata i menadţmentu u
cilju prikupljanja relevantnih informacija o vrednosti objekata (PRILOG
III 2E).

- 461 -
1.5. Opšti metod procene rizika

U procesu formalne analize rizika za objekte IKT sistema,

procenjuju se: vrednost objekata-A, pretnje-T, ranjivosti objekata–V i
uticaj-Ut pretnje na iskoristivu ranjivost. Ove procene se uvek nalaze
unutar granica bezbednosnog rizika i smatra se da izvan ovih granica
nema rizika, [23].

Atributima se pridruţuju kvalitativni teţinski faktori (numeriĉki: 1-5, ili

1-10, ili ocena: nizak, srednji, visok, ili sitnije gradacije: nizak, srednje
nizak, srednji, srednje visok, visok i sl.) koji se, zatim, kombinuju
proizvodeći meru relativnog rizika - (Rr) za specifiĉnu ranjivost IKT
sistema. Vrednost rizika se smatra relativnom, zato što se relacija
zasniva na subjektivnom vrednovanju i rangiraju vrednosti atributa A,T,V
i ne uraĉunava faktor neodreĊenosti ovih atributa. Jednaĉina 1.1 je
fundamentalna za procenu rizika i samo je jedna od brojnih matematiĉkih
formulacija u procesu procene rizika:

Rr = A x T x V (1.1)

Jednaĉina 1.1 koristi se za proraĉun Rr za svaku realnu kombinaciju

vrednosti pojedinaĉnih procena A,T,V, bez obzira na mere zaštite. Za
razumevanja procesa procene rizika treba razumeti prirodu i doprinos
svakog pojedinaĉnog atributa. Primeri intuitivne kvalitativne procene
atributa relativnog rizika dati su u Tabeli 1.2.

Primer scenarija Procena A Procena V Procena T Procena

Rr
Korpa sa mesom sa vukovima u Visoka Visoka Visoka Visoka
šumi
Prazna korpa sa vukovima u šumi Niska Visoka Visoka Niska
Meso u hermetiĉkoj zatvorenom Visoka Niska Visoka Niska
kontejneru sa vukovima u šumi
Korpa sa mesom na kuhinjskom Visoka Visoka Niska Niska
stolu

T. 1.2. Primer intuitivne procene atributa A,V,T i relativnog rizika-

Rr

- 462 -
1.5.1. Procena vrednosti objekata - A

Procena vrednosti ili osetljivosti objekata IKT sistema vrši se

unutar granica bezbednosnog rizika, koje moraju biti korektno
uspostavljene u projektnom zadatku i ništa što moţe uticati na
bezbednost sistema, ne sme se ostaviti izvan tih granica.
Vrednost objekata-A zasniva se na metrici generalno prihvatljivih
atributa kvaliteta objekata sistema: poverljivosti-Pv, raspoloživosti-Ra,
integritetu-In i bezbednosnoj pouzdanosti ili iskoristivosti-Po, koji
aditivno doprinose vrednosti objekata. Poslednji atribut Po nije
neophodan, jer malo doprinosi u kombinaciji prva tri, tako da je A suma
prva tri atributa:
A = Pv + Ra+ In +(Po) (1.2)
Za procenu vrednosti objekata-A treba odrediti teţinske faktore (kao kod
Rr) za svaki objekat pojedinaĉno. Skala ponderacije teţinskih faktora
stvar je izbora svake organizacije, a jedna mogućnost prikazana je u
Tabeli 1.3.

Nivo
Teţinski
vrednost Definicija - kriterijumi
faktor
i

Ovi objekti imaju najvišu vrednost za organizaciju i mogu se

vrednovati i više od mreţne i tekuće trţišne oĉekivane vrednosti.
najveći 1
Njihov gubitak ili uništenje moţe imati ozbiljan uticaj na ukupno
poslovanje organizacije.

Ovi objekti imaju vrlo visoku vrednost za procese rada i njihov

srednje
2 gubitak ili uništenje moţe imati ozbiljan uticaj na neke poslove
visok
organizacije.

Ovo su znaĉajni objekti organizacije koji mogu biti zamenjeni, a

srednji 3 njihov gubitak ili uništenje moţe imati trenutne i ozbiljne posledice
za profitabilnost poslova.

srednje Ovo su zamenljivi objekti, a pošto je cena zamene relativno visoka,

4
nizak mogu imati samo umeren uticaj na ukupnu profitabilnost poslova.

Ovo su objekti koji nemaju stvarnu ekonomsku vrednost unutar

najniţi 5
procesa rada i mogu se lako i jeftino zameniti.

T. 1.3. Kriterijumi za odreĊivanje teţinskih faktora vrednosti

objekata -A

- 463 -
1.5.2. Procena pretnji -T

Jedna od mogućih taksonomija (klasifikacije na utvrĊenim

principima) izvora pretnji je grupisanje u 6 sledećih kategorija, [22], [23],
[24]:

 Maliciozne zloupotrebe IKT: planirane, ĉesto sa ispitivanjem

ranjivosti sistema. dolaze izvana i iznutra sistema.
 Maliciozni kompjuterski kriminal: kraĊa, destrukcija, korupcija
izvana ili iznutra,
 Nebriga: korisnika, ne sprovoĊenje procedura, korišćenje preĉica
i.t.d.
 Ljudska greška: sluĉajne, glavni izvori incidenata;
 Pad sistema: moţe imati katastrofalne posledice za IS i poslovni
sistem;
 Okruženje: prirodne katastrofe mogu biti ozbiljne pretnje – grom,
toplota, vatra, zemljotres i.t.d. Jedini naĉin suprostavljanja je izrada i
verifikacija Plana za vanredne situacije i Plana za odrţavanje
minimuma procesa rada.

Generalno, teţinske faktore izvora pretnji treba kategoristi od najvećih do

najmanjih, n.p.r. pretnje od ljudi imaju veće teţinske vrednosti od
prirodnih dogaĊaja.

Moguće su brojne taksonomije pretnji u odnosu na razliĉite kriterijume.

Po prirodi izvora pretnje mogu biti sluĉajne-Sl i namerne-Na, ali je
verovatnoća pojave neke pretnje uvek sluĉajna veliĉina. U tom smislu
pod sluĉajnim pretnjama u ovoj taksonomiji podrazumevaju se
nenamerne ljudske greške u radu, kvarovi (otkazi hardvera i softvera i
sl.), prirodni vanredni dogaĊaji i.t.d., koje se ne smatraju namernim
napadima na sistem, ali su ozbiljni uzroci bezbednosnih incidenata. Za
analizu rizika od interesa je procena svih pretnji koje izazivaju
bezbednosne incidente.

- 464 -
Za analizu rizika prihvatljiva je taksonomija kombinovanih pretnji u
odnosu na, [18]:

1. posledice uticaja: štetne-Št, neškodljive-Nš,

2. izvor nastanka: iznutra-Un, spolja-Va i
3. način izvoĎenja: sofisticirane – So, nesofisticirane – Ns.

U praksi zaštite ove tri grupe pretnji najĉešće se realizuju u kombinaciji

faktora pretnji, proizvodeći uticaje na hardver, softver, servise i podatke
sa 8 razliĉitih kombinacija pretnji:

ŠtSoUn, ŠtSoVa, ŠtNsUn, ŠtNsVa, NšSoUn, NšSoVa, NšNsUn,

NšNsVa.

Primeri svakog od 8 kombinovanih tipova pretnje dati su u Tabeli 1.4.

Pretnja - Opis i/ili primer

T
Št So Un Aktivnosti nezadovoljnog sistem administratora
Št Ns Un, Aktivnosti nezadovoljnog zaposlenog (ne-administratora)
Nš So Un Aktivnosti znatiţeljnog administratora (izveštaj testiranja poslednjih ranjivosti)
Sluĉajno oštećenje od strane administratora (brisanje sistema ili datoteke
korisnika)
Nš Ns Un Aktivnosti znatiţeljnog korisnika (pogaĊanje pasvorda)
Sluĉajno oštećenje od strane znatiţeljnog korisnika (brisanje datoteke)
Št So Va Industrijska špijunaţa. Aktivnosti veštog osvetoljubivog napadaĉa
Št Ns Va Aktivnosti napadaĉa ograniĉenih sposobnosti, ali jako zainteresovanih za
specifiĉne objekte (e-mail spam ili trial-and-error napadi)
Nš So Va Aktivnosti veštog, odluĉnog i znatiţeljnog korisnika (ĉovek vs. mašina )
Nš Ns Va. Aktivnosti znatiţeljnog korisnika ("šta ovo radi?").
Nenamerna aktivnost koja se moţe interpretirati kao maliciozna

T. 1.4. Primeri tipova kombinovanih pretnji

a. Proračun težinskih faktora intenziteta potencijalnih pretnji: potrebno

je proraĉunati za svaki objekat sistema. Iako svaka organizacija bira sama
svoj sistem ponderacije, sugerišu se sledeći kriterijumi za ponderisanje
intenziteta potencijalnih pretnji (T.1.5):

- 465 -
 Teţinski
Nivo Definicija
faktor

Posledica pretnje je potpuno uništenje objekata, od

eliminiše 1 ĉega se organizacija teško moţe oporaviti.
Najopasniji incident, teški za kontrolu i zaštitu.

Incidenti mogu biti razorni i bez neposrednog i

adekvatnog odgovora potpuno uništiti objekte.
razoran 2
Dovode do znaĉajnih finansijskih gubitaka i gubitka
javnog ugleda.

Incidenti od kojih se organizacija moţe oporaviti

paţljivim upravljanjem incidentom i
kritiĉan 3
implementacijom odgovarajućih mera zaštite. Dovode
do srednjih finansijskih gubitaka i neprijatnosti.

Uticaj incidenta je verovatno kratkoroĉan i moţe se

kontrolisati. Sa pravom zaštitom i odgovorom, uticaj
kontrolisan 4
moţda moţe bit i smanjen na minorne neprijatnosti i
minimalne troškove.

Incidenti su obiĉno beznaĉajni i izazivaju samo

iritirajući 5 lokalnu iritaciju. Merama zaštite treba ih izbeći ili
kontrolisati.

T.1.5. Kriterijumi za ponderaciju intenziteta potencijalnih pretnji

- 466 -
b. Proračun težinskih faktora frekvencije pojave pretnje: potrebno je
izvršiti za svaki objekat. Iako svaka organizacija bira sama svoj sistem
ponderacije, sugeriše se primena sledećih kriterijuma (T. 1.6):

Teţinski
Nivo Definicija
faktor

Vrlo Frekvencija incidenta je vrlo visoka, a incident moţe biti

1
visok razoran za proizvodnju ili servise.

Visok 2 Frekvencija incidenta je visoka i moţe se ponoviti.

Incident se potencijalno moţe priliĉno ĉesto dogoditi, ali

Srednji 3
normalno nije predvidiv.

Incident ima nisku frekvenciju pojavljivanja i smatra se

Nizak 4 da nije ponovljiv. Ne bi trebalo biti više od 1 incidenta u
1 radnom ciklusu.

Vrlo
5 Ovaj incident se smatra vrlo retkim i periodiĉnim.
nizak

T. 1.6. Proraĉun teţinskih faktora frekvencije pojave bezbednosnog

incidenta

- 467 -
c. Proračun težinskih faktora za verovatnoću pojave bezbednosnog
incidenta: potrebno je izvršiti za svaki objekat sistema. Iako svaka
organizacija bira sama svoj sistem ponderacije, moguća je primena
sledećih kriterijuma (T. 1.7):

Teţinski
Nivo Definicija
faktor

Vrlo Pretnja ima vrlo visoku verovatnoću dogaĊanja, sve dok

1
visok se ne primene korektivne aktivnosti.

Pretnja ima visoku verovatnoću dogaĊanja, ako nisu

Visok 2
primenjene korektivne akcije.

Srednji 3 Pretnja ima umerenu verovatnoću dogaĊanja.

Rizik od dogaĊanja ove pretnje smatra se da je vrlo

Nizak 4
nizak.

Vrlo Postoji vrlo niska verovatnoća da će se ovaj incident

5
nizak dogoditi.

T.1.7. Proračun težinskih faktora za verovatnoću bezbednosnog

incidenta

Za proraĉun se mogu koristiti i praktiĉni elementi za alternativnu procenu

verovatnoće pretnje–incidenta za najveći broj tipova poznatih
potencijalnih pretnji, mereni statistiĉkom verovatnoćom od 0-1 ili
numeriĉkim, kvalitativnim teţinskim faktorima od 0-5 i primeri
kvalitativnog merenja, ponderisanja i razliĉite kvalitativne metode
proraĉuna stepena neodreĊenosti pretnji – verovatnoće i intenziteta
dogaĊaja, prikazani u tabelama 1. do 7. U PRILOGU III 2F.

1.5.3. Procena ranjivosti sistema -V

OdreĊivanje vrednosti informacija/objekata osnova je za primenu bilo

kojeg rešenja mera zaštite. Ovaj proces se izvršava korišćenjem formalne
metodologije teorije informacija, a sve neformalne metode su više ili
manje subjektivne. U trendu je rešavanje zadataka zaštite informacija
primenom kvalitativnih metoda (tj. ne samo deterministiĉkih nego i
sluĉajnih kao i neureĊenih skupova.

- 468 -
Sistem se smatra ranjivim (V) kada postoji mogućnost da se dogodi
gubitak ili nastane šteta. Rangiranje taĉaka ranjivosti vrši se prema
proceni veliĉine potencijalne štete koja moţe nastati iskorišćenjem te
ranjivosti od strane nekog agenta pretnje. Na primer, ranjivost koja
dopušta korisniku da neovlašćeno dobije prava administratora treba da
dobije veći teţinski faktor, nego da - ĉita tuĊu e-poštu. Postoji više
manuelnih i programskih metoda za proraĉun vrednosti faktora
ranjivosti-V, raspoloţivih na Internetu. Za razliku od aditivnih
komponenti vrednosti objekata-A, mere vrednosti ranjivosti sistema-V se
multipliciraju, na primer, ako ima 20 raĉunarskih sistema sa po 15
ranjivih taĉaka, onda je ukupna ranjivost IKT sistema: V=20x15=300.

U PRILOGU III 2G navedeni su bezbednosni kriterijumi za korišćenje

u proceni ranjivosti sistema u oblasti upravljaĉkih, operativnih i tehniĉkih
kontrola. Izlaz iz procesa procene ranjivosti je kontrolna lista
bezbednosnih zahteva za bezbednosne popravke identifikovanih
ranjivosti (Tabela 1.). U Tabeli 2. nabrojane su kljuĉne ranjivosti IKT
sistema OSI modela arhitekture, sa predlogom osnovnih servisa i
kontrola (mera) zaštite od iskorišćavanja navedenih ranjivosti.

Relevantni teţinski faktori ranjivosti objekata IKT sistema odreĊuju se,

sa aspekta agenta pretnje, u odnosu na atribute: vidljivost ili
detektibilnost, korisnost, trajnost, iskoristivost i zaštićenost. Teţinske
faktore treba procenjivati i raĉunati za svaku poznatu taĉku ranjivosti u
odnosu na ove atribute.

Primer upitnika za procenu ranjivosti-V na osnovu pet atributa, sa

aspekta zaštite poverljivosti informacija, poreĊanih po prioritetima od
najznaĉajnijeg za ranjivost (1) do najmanje znaĉajnog-(5)), a
procenjivanih na osnovu odgovora na postavljena pitanja, prikazan je u
Tabeli 1.8, [18].

- 469 -
 Atributi
ranjivosti Procena ranjivosti-V
sistema
(1) Vidljivost ili
Verovatnoća da kompetentan agent pretnje postane svestan
detektibilnost
vrednosti informacije i da moţe pristupiti ovim informacijama.
(D)
(2) Korisnost Verovatnoća da agent pretnje uvidi korisnost informacije, da će
(Ko) informacija zadovoljiti neku zainteresovanu u stranu ili da će
zadovoljiti zahteve konkurencije.
(3) Trajnost
Datum iza koga informacija više neće biti korisna napadaĉu i
(Tr)
mogućnost korišćenja informacije pre toga datuma.
Mogućnost upotrebe informacije na vreme i na naĉin koji su
(3) Iskoristivost
kritiĉni za vlasnika informacije. Potreba za dodatne informacije
(Is)
da bi napadaĉ iskoristio originalne informacije i stekao prednost
ili ugrozio vlasnika informacije.
Postojanje dokumentovane politike zaštite poslovnih tajni ili
(4) Zaštićenost intelektualne svojine. Pristup korisnika informacijama
(Za) ograniĉen u skladu sa politikom zaštite. Korisnici su potpisali
sporazum o neotkrivanju informacija NDA (Non Disclosure
Agreement).

T. 1.8. Primer procene relevantnih faktora ranjivosti

Svakom odgovoru u T.1.8. pripisuje se jedan od ponuĊenih teţinskih

faktora primenjene metrike (1-5, 1-10; nizak, srednji, visok i.t.d.) onako
kako ih procenjuju vlasnici objekata (menadţeri). Ranjivost objekata IKT
sistema ĉesto je teško procenjivati pre incidenta, jer u suštini najĉešće
napad potvrĊuje da li postoji ranjivost u hardveru, softveru, poslovnim
procesima i ljudima. Ranjivost je sve ono što se moţe iskoristiti za
dobijanje odreĊene prednosti u odnosu na sistem. U ovom procesu pored
liste pitanja za glavne atribute parametra ranjivosti u T 1.8., obavezno
treba ispitati sledeću listu taĉaka ranjivosti:

 nedostatak ili neadekvatnost politike, standarda i procedura,

 nedostatak ili neadekvatnost obuke,
 loše definisane uloge i odgovornosti, dodeljeni nalozi i ovlašćenja,
 poznate greške sistemskog/aplikativnog softvera,
 nestabilnost OS i veliki broj pristupnih taĉaka raĉunarskoj mreţi,
 mogućnost fiziĉkog pristupa prostorijama sa raĉunarima/serverima.

- 470 -
U procesu procene ranjivosti sistema, korišćenjem metode odreĊivanja
teţinskih faktora, treba procenjivati ranjivosti po svim glavnim
atributima za svaku taĉku ranjivosti, a zavisno od zahtevane dubine
analize rizika, moguće je primeniti metod analize rizika procesa rada,
funkcionalnih celina, kritiĉnih objekata ili strukturni metod brze analize
rizika (BAR), [25].

1.5.4. Procena uticaja pretnji na ranjivosti sistema

Uticaj -Ut je mera efekata i negativnih posledica koje na IKT

sistem moţe izvršiti neki,[23]:

1. Izvor slučajne pretnje ako postoji:

- dogaĊaj/incident unutar perimetra bezbednosnog rizika i
- ranjivost sistema, koju moţe ta pretnja iskoristiti.
2. Izvor namerne pretnje, ako postoji:
- stimulacija poĉinioca: motiva, odluĉnost, resursi, sposobnost,
prilika, atraktivnost,
- dogaĊaj/incident unutar perimetra bezbednosnog rizika i
- ranjivost koju ta pretnja moţe iskoristiti.

Uticaj moţe biti primarni ili sekundarni. Primeri primarnih uticaja na

objekte IKT sistema mogu biti: neovlašćeno otkrivanje i/ili
namerna/sluĉajna modifikacija, neraspoloţivost i/ili destrukcija podataka
i servisa. Sekundarni uticaji se, takoĊe, moraju uzeti u obzir (npr. poţar u
zgradi spreĉava pristup podacima i drugim objektima IKT sistema). Za
uticaj intenziteta, verovatnoće i frekvencije pojave svakog tipa pretnji na
pojedinaĉne objekte treba proraĉunati teţinski faktor tog uticaja, pri
ĉemu treba razmatrati prednosti i nedostatke kvantitativnih i kvalitativnih
metoda merenja i procene nivoa uticaja. Generiĉki uticaj pretnji na
„trougao― glavnih bezbednosnih ciljeva zaštite: poverljivosti, integriteta i
raspoloživosti informacija prikazan je grafiĉkim modelom na Sl. 1.4.

- 471 -
 Neovlašćeno
otkrivanje Informacije Neovlašćeno
korišćenje

Poverljivost

Raspoloţivost Integritet

Zaštita
Neovlašćena
Neovlašćena
modifikacija
destrukcija i DoS

Sl.1.4. Uticaj pretnji na glavne bezbednosne ciljeve

Glavna prednost kvalitativne analize uticaja je u odreĊivanju prioritetnih
faktora rizika i identifikaciji zona ranjivosti koje neposredno treba
otklanjati. Nedostatak kvalitativne analize uticaja rizika je u tome što ne
obezbeĊuje specifiĉne kvantitativne mere i procenu troškova-koristi (cost
- benefit) preporuĉenih kontrola zaštite. Glavna prednost kvantitativnih
metoda analize uticaja rizika je što obezbeĊuje merenje veliĉine uticaja i
cost-benefit analizu preporuĉenih kontrola zaštite. Nedostatak ovih
metoda je, zavisno od izbora numeriĉkih opsega faktora ponderacije,
nejasnost i ĉesta potreba kvalitativne interpretacije rezultata.
Primer kvalitativne procene i odreĊivanja teţinskih faktora uticaja rizika,
koji obuhvata komponente vrednosti objekata-A, intenzitet pretnje-Ti,
frekvenciju pretnje-Tf i verovatnoću pretnje-Tv prikazan je u Tabeli 1.9.

- 472 -
 Komponente uticaja rizika Teţinski faktori

Vrednost objekta -A 1 - 5 (1 je najveći)

Intenzitet potencijalne pretnje-Ti 1 - 5 (1 je najveći)

Frekvencija potencijalne pretnje

1 - 5 (1 je najveći)
(incidenta)-Tf

Verovatnoća pretnje (incidenta)-Tv 1 - 5 (1 je najveći)

T. 1.9. Komponente odreĊivanja teţinskih faktora uticaja rizika

Za proraĉun ukupnog teţinskog faktora uticaja pretnje-rizika potrebno je

mnoţiti svaku komponentu uticaja rizika jednu sa drugom:

Ut = A x Ti x Tf x Tv (1.3)

U ovom modelu formalizacije, što je dobijeni težinski faktor manji –

uticaj rizika je veći. Najveći teţinski faktor rizika po ovoj skali
ponderacije je 1, a najniţi 5x5x5x5=625. Svaki rezultat manji od 50
zahteva hitnu istragu.

OdreĊivanjem teţinskih faktora uticaja rizika, moguće je rangirati

kritiĉnijih 20-30 objekata organizacije za procenu rizika metodom
OCTAVE i faznom implementacijom. Kada se korektivne mere zaštite
implementiraju, novom revizijom uticaja faktora rizika treba da se
izraĉuna preostali rizik – Rrp i obezbedi njegova prihvatljivost u
organizaciji.

- 473 -
 1.6. Proraĉun faktora preostalog rizika metodom rentabiliteta

Rizik koji ostaje posle implementacije novih ili poboljšanih kontrola

zaštite naziva se preostali relativni rizik - Rrp. To znaĉi da ni jedan IKT
sistem nije osloboĊen rizika i da sve implementirane kontrole ne
eliminišu u potpunosti odnosne faktore rizika. Nivo Rrp moţe se
analizirati kao iznos redukovanog rizika uvoĊenjem novih, poboljšanih
kontrola zaštite u odnosu na procenu uticaja pretnji. Implementacija
novih i poboljšanih kontrola zaštite moţe smanjiti rizik eliminisanjem
nekih ranjivosti, dodavanjem kontrola zaštite i smanjenjem veliĉine
negativnog uticaja (Sl.1.5).

Redukvan broj grešaka

Nove ili poboljšane Dodavanje namenskih

kontrole Preostali rizik - Rrp
kontrola

Redukcija veličine uticaja

Sl. 1.5. Implementirane kontrole zaštite i preostali rizik-Rrp

Za svaku kombinaciju A, T i V treba izraĉunati faktore relativnog rizika-

Rr prema jednaĉini 1.1. mnoţenjem tih vrednosti. Kako svaka od
mogućih kombinacija pretnji- T ne moţe iskoristiti svaku ranjivost
sistema, bolju aproksimaciju za svaku vrednost A i V daje jednaĉina:

Rr=AxVx  T (1.4)

gde je  T kombinovana pretnja (1-8), a T - tip pretnje koji ima uticaj

na dati par A i V.

Kako je rizik identifikovan prema tipu specifiĉnih objekata i ranjivosti

sistem će imati jednu vrednost rizika po jednoj taĉki ranjivosti koju

- 474 -
pretnja iskoristi, a svaka ranjivost će imati jednu vrednost rizika po
objektu na koji utiĉe.

Ne postoji egzaktna matematiĉka relacija za kvantitativan proraĉun

relativnog preostalog rizika-Rrp koji nameće u datoj situaciji
kombinovana pretnja-T na ranjivost objekta-V sa primenjenim merama i
metodama zaštite-Mz za ublaţavanje rizika. Proces procene rizika daje
dva rezultata: preostali relativni rizik bez uĉešća mera zaštite-Rrp i
prihvaćeni rizik sa merama zaštite-Rpp. Pribliţno se nivo preostalog
relativnog rizika sa merama zaštite-Rpp moţe proraĉunati iz jednaĉine,
[18]:

Rpp= ((AxVx  T)/Mz) x Ut (1.5)

Uticaj pretnje-Ut na sistem posle uspešnog napada zavisi od vrednosti

objekta napada. Kako raste A, raste i Ut, odnosno, raste i nivo Rpp, a na
porast nivoa faktora rizika direktno utiĉu kombinovane pretnje-T i
ranjivosti sistema-V. Mere zaštite- Mz smanjuju nivo Rpp.

Efektivnost uvoĊenja mera zaštite –Emz moţe se proraĉunati formulom:

Emz= (Rpr-Rpp)/Rpr (1.6)

Temeljita evaluacija faktora rizika je kamen temeljac razvoja programa i

plana rentabilnog sistema IKT zaštite. U plan zaštite korisno je ubaciti
ukupne troškove zaštite, koji na preostalom nivou rizika-Rpr treba da
budu minimalni i manji od ukupno oĉekivanih godišnjih gubitaka –
OGG, koji mogu nastati ako se ne primene predviĊene mere zaštite,
odnosno, ostvari uticaj pretnje-Ut. OGG treba da budu manji od ukupnog
preostalog relativnog rizika-Rpr izraţenog u novĉanoj vrednosti. Ovakva
vrednost Rpr najĉešće se predlaţe menadţmentu, kao vrednost
prihvatljivog nivoa ukupnog rizika-Rpp. Kako je vrednost OGG jednaka
vrednosti uticaja-Ut izraţenoj u novĉanim jedinicama, OGG se mogu
proceniti sliĉnom iskustvenom relacijom, [22]:

OGG = Tv x Ar (1.7)

gde je: Tv- verovatnoća da će se neka pretnja materijalizovati u datoj

godini, a

- 475 -
 Ar- relativna vrednost odreĊene imovine na koju se pretnja odnosi.

Primer: Lokalna mreţa IKT sistema ima 20 PC po ceni od 540 Eu po

komadu. Oĉekuju se po 1 potpuni prekid rada (pad sistema), upad u
sistem i kraĊa podataka godišnje (T=1). Primenom formule (1.7) biće:
OGG= 1x (20 x 540) = 10.800 Eu, pa su sve primenjene kontrole zaštite
za spreĉavanje ove procenjene štete rentabilne, ako im cena ne prelazi
OGG.

Ukupan rizik je kombinacija pojedinaĉnih faktora A, T, V. Izmena bilo

kojeg faktora menja profil rizika. U IKT sistemu neophodno je uvesti
aktivno upravljanje rizikom sa regularnom revizijom.

Dijagram toka preporuĉene metodologije za ublažavanje rizika i

specifiĉne iskustvene preporuke za upravljanje rizikom dati su u
PRILOGU III 2H. U PRILOGU III 2I data su radna dokumenta:
tabela, upitnika, kontrolnih lista, uzoraka procedura i izveštaja o analizi
rizika, koja pomaţu analitiĉaru u izvršavanju kompletnog procesa analize
i procene rizika, [18].
U praksi zaštite retko se koristi kompletna formalna metodologija za
analizu i procenu rizika. Razvijeni su brojni skraćeni metodi za analizi
rizika (OCTAVE, BAR) koji su praktiĉniji i brţe dovode do prihvatljivih
rezultata. Da bi se ilustrovala fleksibilnost u izboru i primeni metoda za
procenu rizika, razvijena je Vežba GIII P2A sa primerom proraĉuna
rizika za bezbednost raĉunarske mreţe, primenom redukovane formalne
metodologije. Vežba GIII P2B razvijena je sa ciljem da se podstakne
intuitivni proces individualnog razumevanja opšteg pojma rizika kao
opšte kategorije svake vrste poslovanja.

U poslovnim sistemima raspoloţivost informacija i servisa sistema ĉesto

je primarni zahtev i stavlja se ispred zahteva za zaštitom poverljivosti i
integriteta informacija. U Vežbi GIII P2C primenjen je izabrani
algoritam, dati su primer proraĉuna vremena prekida informacija za
odreĊenu grupu korisnika i metod procene rizika za raspoloţivost
informacija od prekida servisa (DoS napada) sa ciljem da se upotpune
faktori koji mogu uticati na servis zaštite raspoloţivosti informacija
(pored tehniĉke i funkcionalne pouzdanosti razmatrane u Vežbi GI P7A)
i poveća razumevanje teţine napora za obezbeĊivanje raspoloţivosti
informacija u IKT sistemu.

- 476 -
2. REZIME

Upravljanje rizikom je u suštini upravljanje sistemom zaštite.

Analiza rizika je metod za planiranje zaštite. Primenjena metoda i
procedura analize rizika moraju da: opišu analizirani sistem; ugrade
‗bazu znanja‘ o pretnjama, zaštiti i drugim spoljnim komponentama;
dograĊuju bazu znanja sa novim informacijama; memorišu opis sistema
tako da je za novu analizu rizika potrebno uneti samo nove promene.

Stohastiĉka priroda procene pretnji i evaluacije objekata IKT, problemi

su koji oteţavaju korišćenje analitiĉkih metoda u procesu analize rizika.
Procena pretnji ograniĉena je sa faktorom neodreĊenosti, jer ne znamo
kada i kako će se neki štetan dogaĊaj desiti i kakvog će biti intenziteta.
Analiza rizika nije strogo nauĉni metod sa pozitivistiĉkog aspekta, nego
pre artefakt koji se koristi za kreiranje profesionalnih znanja.

Drugi problem su kvalitativna i kvantitativna identifikacija i vrednovanje

objekata IKT, gde su podaci i informacije najznaĉajnije vrednosti.
‗Vrednost‘ podataka moţe se dobiti samo indirektnim putem korišćenjem
faktora ‗uticaja‘ pretnji na ranjive taĉke sistema (otkrivanje,
modifikacija, neraspoloţivost, destrukcija). Nemoguće je proceniti ove
efekte bez specifiĉnog scenarija. Ĉesto je nemoguće napraviti evaluaciju
materijalnih troškova gubitaka.

Dinamiĉka 'dimenzija' analize rizika je vaţna, jer se pretnje i drugi

faktori uvek menjaju. Ovo znaĉi da se i nivoi zaštite moraju menjati tako
da kompenzuju ove promene. U ovakvom procesu kontrole, analiza
rizika je model donošenja odluke koji pomaţe upravnoj strukturi da
planira sistem zaštite. Faktor promenljivosti unosi i unutrašnje i spoljno
okruţenje, pa je za upravljanje promenama.potrebno neprekidno
skeniranje specifiĉnih dogaĊaja u okruţenju, Promene u sistemu mogu
izazvati interni dogaĊaji (novi sistem aplikacija, novi ili glavni softver,
hardver ili komunikacije, novi zaposleni, nova odelenja i sl.) ili promene
u ţivotnom ciklusu sistema (revizija zahteva, preliminarnog i kritiĉnog
dizajna; implementacija sistema; monitoring i periodiĉna revizija).

Brojni metodi kvantitativne analize rizika imaju prednosti, jer svode

svaku analizu rizika na novĉanu vrednost. Kada je u pitanju gubitak
ţivota ili nacionalnog interesa, treba primeniti kvalitativnu procenu
znaĉaja gubitaka umesto novĉanih vrednosti. Sa procedurom koja

- 477 -
odreĊuje prioritete, kvantitativna analiza rizika ima problem memorisanja
i akvizicije podataka. Dobar interaktivni (program-ĉovek) kvalitativni
metod za analizu rizika je CRAMM, kojeg koristi više od 40 zemalja u
svetu na nacionalnom nivou (za drţavne potrebe). Primena metoda nije
jednostavna i zahteva dobru obuku analitiĉara. Pogodnije za primene su
verzije brzih (Express CRAMM) metoda. Metod OCTAVE je evaluacija
bezbednosnog rizika IKT sistema organizacije fokusirana na kritiĉne
objekte organizacije i faktore rizika za ove objekte. Metod je
sveobuhvatan, sistematiĉan, adaptivan promenama realne situacije i
samonavodeći. Omogućava svim zaposlenim na svim nivoima
organizacije da rade zajedno na identifikaciji i razumevanju faktora rizika
i da donesu pravilne odluke za smanjenje rizika i sistem zaštite. Metod
brze analize rizika (BAR) omogućava brzu i efektivnu analizu glavnih
faktora rizika, sa ukljuĉivanjem kapaciteta organizacije i bez potrebe
posebnog angaţovanja specijalista za analizu rizika.

- 478 -
3. KLJUĈNI TERMINI

Agent pretnje: entiteti (lice, organizacija, stvar) koji su sposobni da

namerno ili nenamerno pokrenu neki dogaĊaj, iskoristite ranjivosti sistema
kompromituju sistem zaštite objekata IKT sistema organizacije i nanesu
štetu.
Akreditacija: formalna deklaracija odgovornog lica kojom se odobrava
rad automatskog raĉunarskog sistema u posebnom reţimu zaštite.
Akreditacija je zvaniĉno ovlašćenje od upravne strukture za rad sistema i
prihvatanje preostalog rizika. Akreditacija je bazirana na procesu
sertifikacije (izdavanja potvrde) i drugim razmatranjima upravne
strukture
Analiza rizika: analiza vrednosti (osetljivosti) objekata IKT sistema,
ranjivosti sistema i potencijalnih pretnji, procena verovatnoće i
intenziteta uticaja pretnji, iskorišćavanjem otkrivenih ranjivosti, na
objekte sistema i poslove organizacije u celini, da bi se izraĉunali
oĉekivani gubici (materijalni i nematerijalni).
DogaĊaj pretnje: dogaĊaj ili pojava koja ima potencijal da
kompromituje sistem zaštite; sinonim je – napad.
Izjava o osetljivosti (IoS): profil postojećeg ili predloţenog sistema koji
dokumentuje karakteristike procesiranih podataka i informacija,
predloţenog personala i zahteva za zaštitu poverljivosti, integriteta i
raspoloţivosti.
Kompromitacija: neovlašćeno otkrivanje, destrukcija, uklanjanje,
modifikacija ili prekidanje rada nekog objekta sistema.
Mera(e) zaštite: odobrene minimalne mere zaštite koje, korektno
primenjene, spreĉavaju ili smanjuju rizik nastao iskorišćenjem
specifiĉnih ranjivosti.
Motivacija: psihološki stimulans koji navodi agenta pretnje da deluje
protiv sistema.
Napad: dogaĊaj ili pojava koja ima potencijal da kompromituje sistem
IKT zaštite.
OGG: oĉekivani godišnji gubici koji se mogu oĉekivati, ako se sistem
zaštite ne primeni.
Posledica: rezultat realizacije pretnje/napada/uticaja agenta pretnje, koji
se izraţava uglavnom u neţeljenim promenama stanja sistema IKT
zaštite. Sinonimi su uticaj i povreda.
Potencijalni uticaj: na organizaciju i pojedince realizuje neki agent
pretnje ili bezbednosni incident probojem sistema zaštite, tj. kada doĊe
do gubljenja poverljivosti, integriteta ili raspoloţivosti informacija.

- 479 -
Procena pretnje: evaluacija karakteristika agenta pretnje ukljuĉujući
resurse, motivaciju, nameru, kapacitet (sposobnost) i priliku.
Procena rizika: analiza faktora rizika bazirana na efikasnosti postojećeg
sistema zaštite; analiza verovatnoće da će ranjivosti sistema biti
iskorišćene od potencijalnih pretnji i da će nastale posledice
kompromitovati objekte IKT sistema.
Ranjivost: karakteristika sistema (slabost, greška) koja dopušta da se
pretnja realizuje.
Resursi (agenta pretnje): oprema, novac, ljudi, znanje i.t.d. koji su na
raspolaganju agentu pretnje da inicira napad.
Rizik: mera verovatnoće da će posledice nekog dogaĊaja prouzrokovati
kompromitaciju objekata IKT sistema.
Scenario pretnje: specifiĉan agent pretnje koji preduzima specifiĉan tip
napada u pokušaju da kompromituje (na jedan ili više naĉina) jedan ili
više objekata IKT sistema.
Sertifikacija: sveobuhvatna procena tehniĉkih i netehniĉkih
karakteristika zaštite IKT sistema, napravljena za podršku procesu
akreditacije, koji uspostavlja meru do koje sistem zadovoljava
specificiranu politiku zaštite.
Sredstva: mehanizam ili medijum kojeg koristi agent pretnje u sluĉaju
napada.
Stanje: opis objekata sistema, pretnji, sistema zaštite i njihovog
okruţenja, kada se zadrţava dati skup uslova; koristi se za modelovanje
promena koje se mogu desiti izmeĊu dva stanja.
Uticaj: mera stepena oštećenja ili druge promene uzrokovane sa nekom
posledicom napada.
Vrednost objekata: (osetljivost) mera ili izjava korisnosti (znaĉaja)
nekih objekata IKT sistema (ili alternativno cene), ako su isti
kompromitovani; vrednost se moţe meriti kvantitativnim ili kvalitativnim
metodama; korisnost ili cena su kontekstualno zavisni, bazirano na
potrebama i situacijama organizacije; zbog toga, vrednost nije nuţno
objektivan pojam.

- 480 -
4. LITERATURA

1. A Reoprt to the Secretary of Defense and the Director of

Central Intelligence, Redefining Security, www.dod.gov,
febrar 1994.
2. American Bar Association Privacy & Computer Crime
Committee Section of Science & Technology Law,
International Strategy for Cyberspace Security,
www.abapccc.com, august 2003.
3. Badenhurst K., Eloff J., "Computer Security Methodology:
Risk Analysis and Project Definition", Computers & Security,
Elsevier Press, N.York, Vol. 9, 1990.
4. Banks S., Computers and Security, "Security Policy", Elsevier
Press, New York, Vol. 9, 1990.
5. Barker William C., Guide for Mapping Types of Information
and Information Systems to Security Categories, NIST
SP800-60 -1 i 2, http://www.nist.gov/publications, juni 2004.
6. Bennett S.P., Kailay M.P., An Application of Quantitative
Risk Analysis to Computer Security for the Commercial
Sector, The 8th Annual Computer Security Applications
Conference, IEEE Computer Society Press, New York, 1992.
7. Bilbao A., "TUAR: A Model of Risk Analysis in the Security
Field", The Carnahan Conference on Security Technology,
IEEE Press, New York, 1992.
8. Carrol M.J., Computer Security, Butterworth-Heinemann,
1997.
9. CCIMB-99-031, Common Criteria for Information
Technology Security Evaluation, Part 1: Introduction and
general model, Version 2.1, http://www.commoncriteria.org,
1999.
10. CRAMM, www.crammusergroup.org.uk, , 2004.
11. Drake D. L., Morse K. L., "The Security – Specific Eight
Stage Risk Assessment Methodology", Proceedings of the 17th
National Computer Security Conference, Baltimore,
Maryland, October 1994.
12. Garrabrants W. M., Ellis III A. W., Hoffman L. J., Kamel M.,
"CERTS: A Comparative Evaluation method for Risk
Management Methodologies and Tools", The 6th Annual
Computer Security Applications Conference, IEEE Computer
Society Press, New York, 1990.

- 481 -
13. Introduction to the OCTAVE®Approach,
http://www.cert.org/octave, 2004.
14. ISACA, Information Systems Audit and Control Association,
www.isaca.org, 2003.
15. IT Governance Institute, COBIT (Control Objectives for
rd
Information and related Technology) 3 Edition, 2000,
www.ITgovernance.org, www.isaca.org.
16. Lavine C. H., Lindell A. M., Guarro S. B., "The Aerospace
Risk Evaluation System (ARiES) Implementation of a
Qualitative Risk Analysis Methodology for Critical Systems",
Proceedings of the 17th National Computer Security
Conference, Baltimore, Maryland, October 1994.
17. Meadows C., Extending the Brewer-Nash Model to a
Multilevel Context, Symposium on Research in Security and
Privacy, IEEE, May 1990.
18. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII.
decembar, 2005.
19. NIST, FIPS 199–FISMA (Federal Information Security
Management Act of 2002-PublicLaw107-347),
www.fips.com, decembra 2003.
20. OCTAVE®Method Implementation Guide,
http://www.cert.org/octave/osig.html, 2004.
21. OCTAVE®-S (version 0.9), http://www.cert.org/octave,
2004.
22. Orlandi E., "The Cost of Security", The Carnahan Conference
on Security Technology, IEEE Press, New York, New York,
1991.
23. Ozier W., "Risk Analysis and Assessment, Handbook of
Information Security Management 1999, CRC Press, Boca
Raton, Florida, 1999.
24. Petrović R. S., Kompjuterski kriminal II Izdanje, MUP
Republike Srbije, 2001.
25. Purser S., A practical Guide to Managing Information
Security, Artech House, Boston-London,
www.artechhouse.com, 2004.
26. Russel D., Gangemi G.T. sr, Computer Security Basics,
O‘Reilly and Ass., SAD, 1992.

- 482 -
3. UPRAVLJANJE PERSONALNOM ZAŠTITOM

0. UVOD

Po završetku ovog poglavlja razumećete kako se:

- određuje značaj personalne zaštite u IS

- upravlja procesom popune radnih mesta u IS
- upravlja korisničkim nalozima
- kontroliše proces upravljanja korisničkim nalozima
- upravlja personalnom zaštitom u IS sa javnim pristupom

Većina najvaţnijih pitanja zaštite ukljuĉuje ljudski faktor:

korisnike, projektante, specijaliste za implementaciju i menadţere zaštite.
Širok spektar pitanja personalne zaštite odnosi se na interakciju ovih lica
sa objektima IKT sistema, u procesu dobijanja pristupa i ovlašćenja
(autorizacije) koja su potrebna za obavljanje njihovih poslova.

Personalna zaštita obuhvata i popunu kadrova za rad u IKT sistemu

organizacije, administraciju korisnika koji rade sa objektima sistema,
ukljuĉujući zabranu pristupa zaposlenih odreĊenim objektima IKT
sistema, kao i administraciju pristupa javnim servisima i pristupa
zaposlenih po ugovoru. Personalna zaštita usko je vezana sa servisom
logiĉke kontrole pristupa.

- 483 -
1. PROCES POPUNE RADNIH MESTA U IKT SISTEMU

Proces popune radnih mesta u IKT sistemu (Sl.1) ukljuĉuje najmanje 4

faze i moţe se primeniti na korisnike i menadţere aplikacija, menadţere
IKT sistema i specijaliste zaštite, [8]:

1. Definisanje radnog mesta, ukljuĉujući razvoj i opis radnog mesta

i odgovornosti;
2. OdreĎivanje najvišeg nivoa osetljivosti objekata IKT kojima lica
mogu pristupiti;
3. Popuna radnih mesta i
4. Obuku.

OdreĎivanje
Definisanje Poppuna
osetljivosti Obuka
radnog mesta radnog mesta
radnog mesta

Sl. 1. Proces popune zaposlenih u IKT sistemu

U fazi definisanja i opisa radnih mesta, moraju se definisati i razmotriti
sva pitanja zaštite. Kada se radno mesto definiše u opštim crtama,
odgovorni menadţer treba da odredi tip pristupa IKT sistemu za to radno
mesto. Kod davanja prava pristupa treba primenjivati dva opšta principa:
razdvajanje dužnosti i davanje minimalnih privilegija.
Razdvajanje dužnosti odnosi se na deljenje uloga i odgovornosti tako da
ni jedan pojedinac nije nezamenljiv i da ne moţe sabotirati kritiĉne
procese. Dobro definisanje tih radnih mesta i duţnosti zaposlenih,
obaveza je menadţera organizacije. Minimum privilegija je bezbednosni
zahtev koji oznaĉava da se korisnicima daju samo pristupi neophodni za
obavljanje poslova, a ne da imaju ekstremno malo prava pristupa
objektima sistema.
U opštem sluĉaju za smanjenje rizika, za organizaciju je efektivnije
koristiti navedene principe za osetljiva radna mesta, nego bezbednosnu
zaštitu zaposlenih. Primena ovih principa moţe ograniĉiti štete od
sluĉajnog incidenta, grešaka ili neovlašćenog korišćenja objekata IKT
sistema. Primena minimuma privilegija ne sme uticati na zamenljivost
zaposlenih na odreĊenim radnim mestima, uz prihvatljivo kašnjenje. Kod
odreĊivanja privilegija, treba konsultovati zahteve iz plana upravljanja
vanrednim dogaĊajem i kompjuterskim incidentom.

- 484 -
1.1. OdreĊivanje osetljivosti radnog mesta

Za odreĊivanje osetljivosti radnog mesta potrebno je poznavati

opis radnog mesta i nivoe pristupa koje radno mesto zahteva. Odgovorni
menadţeri treba da korektno identifikuju nivoe osetljivosti radnog mesta
tako da se moţe kompletirati odgovarajuća i rentabilna personalna
zaštita. U opštem sluĉaju, razliĉiti nivoi osetljivosti pripisuju se razliĉitim
radnim mestima, na bazi stepena štete (npr. otkrivanje privatnih
informacija, prekid kritiĉnih procesa i sl.) koju pojedinci mogu izazvati
zloupotrebom IKT sistema, ili pristupom osetljivim informacijama,
procesiranim na radnom mestu. Broj osetljivih radnih mesta treba biti
racionalan, pošto zaštita prevelikog broja osetljivih radnih mesta zahteva
veća finansijska i druga sredstva, a suviše mali broj moţe izazvati
neprihvatljivo veliki rizik, , [7].

1.2. Popuna radnih mesta – bezbednosna zaštita i izbor zaposlenih

Kada se odredi osetljivost radnih mesta, moţe poĉeti faza popune

radnih mesta, obiĉno sa objavljivanjem javnog konkursa. U konkursu se
navodi koji profil kandidata se zahteva za koje radno mesto.
Bezbednosna provera kandidata, koja pomaţe da se odredi podobnost
nekog lica za odreĊeno radno mesto, treba da bude jedan od uslova za
zapošljavanje. Dok bezbednosna provera ne bude završena, zaposleni se
ne mogu zvaniĉno rasporediti na radna mesta, niti imati pristup osetljivim
informacijama i objektima IKT sistema. Radna mesta se svrstavaju u
kategorije prema osetljivosti materijala i objekata kojima se rukuje na
tom radnom mestu, a menadţeri proveravaju poverljivost i pouzdanost
lica za konkretno radno mesto, [7].

U drţavnom sektoru tipiĉna bezbednosna provera obuhvata proveru

kriviĉnog dosijea u policiji, a detaljna obuhvata i radnu istoriju i
obrazovanje, spisak pokretne i nepokretne imovine u vlasništvu, proveru
korišćenja zabranjenih supstanci, intervjue i razgovore sa kolegama,
prijateljima i.t.d. Obim i intenzitet provere zavise od osetljivosti radnog
mesta. Ako bezbednosna provera utvrdi kompromitaciju, ne znaĉi da lice
automatski nije podobno za neko radno mesto.

U civilnom sektoru bezbednosna provera lica je promenljiva i

neujednaĉena i uglavnom se svodi na proveru liĉnih kvalifikacija, radnog
iskustva i hobija (Curriculum Vitae), koje kandidati dostavljaju uz

- 485 -
zahtev za odgovarajuće radno mesto. Obiĉno se nova lica postavljaju na
manje osetljivo radno mesto. Zaposleni u civilnom sektoru, koji rade za
potrebe drţavne uprave mogu biti podvrgnuti kompletnoj bezbednosnoj
proveri.. Odluku treba doneti u odnosu na vrstu posla, rezultate provere i
druge relevantne faktore.

1.3. Obuka zaposlenih

Prijem lica na neko radno mesto ne znaĉi da je popuna radnog

mesta završena. Zaposleni moraju završiti pripravniĉki staţ i obuĉiti se za
poslove na radnom mestu, ukljuĉujući i za rad na raĉunaru i odgovornosti
u procesu zaštite. Ova obuka moţe promovisati zaštitu i svest o potrebi
zaštite IKT sistema. Na bazi analize rizika, daje se pristup samo liĉnim
raĉunarima (PC), sve dok se bezbednosna provera ne završi. Adekvatno
obuĉeni zaposleni od presudnog su znaĉaja za efektivno funkcionisanje
IKT sistema i aplikacija, pa je obuka novih korisnika kritičan faktor
personalne zaštite. Vaţno uoĉiti da su obuka i obrazovanje iz oblasti
zaštite neprekidni procesi, koji se moraju izvršavati sve dok zaposleni
koriste IKT sistem, [7].

- 486 -
2. UPRAVLJANJE PERSONALNOM ZAŠTITOM

Efektivno administriranje pristupa korisnika IKT sistemu bitno je

za odrţavanje sistema zaštite. Upravljanje korisničkim nalozima
obuhvata servise identifikacije, autentifikacije i autorizacije pristupa,
kontrolu (auditing) i periodiĉne verifikacije legitimiteta naloga i
ovlašćenja pristupa.

2.1. Upravljanje korisniĉkim nalozima

Proces upravljanja korisniĉkim nalozima ukljuĉuje tri kljuĉne faze, [2]:

1. podnošenja zahteva, otvaranja, izdavanja i zatvaranja korisniĉkih

naloga;
2. praćenje korisnika i njihovih odnosnih prava za pristup i
3. upravljanje ovim funkcijama.

Proces tipiĉno poĉinje sa zahtevom menadţera korisnika, upućenim

menadţeru/administratoru IKT sistema, za pristup sistemu, ili za
otvaranje korisniĉkog naloga za zaposlenog. Za pristup nekoj aplikaciji,
zahtev podnesi vlasnik aplikacije menadţeru IKT sistema. Zahtev sadrţi
nivo pristupa kojeg treba dodeliti na osnovu radne funkcije, ili
specifikacije korisničkog profila grupe zaposlenih koji obavljaju iste
poslove. Nivo pristupa po ovom nalogu mora biti konzistentan sa
zahtevom menadţera, a pridruţena ovlašćenja selektivna (direktno u
aplikacije ili u OS). Za pristup aplikaciji korisnici se mogu naknadno
―dodavati‖.

Zaposleni se informišu o njihovim nalozima - identifikatoru naloga (npr.

ID korisnika) i sredstvu za autentifikaciju (npr. pasvord, smart kartica).
Povezivanje korisniĉkog ID sa poloţajem na radnom mestu moţe
pojednostaviti administrativni rad, ali oteţava kontrolu (auditing) i
eventualnu forenziĉku istragu. Povezivanja ID sa individualnim
korisnikom ima veće prednosti. Za svaki pristup moraju se uspostaviti
procedure za upravljanje promenama (posla, ostavka, penzionisanje i
dr.). Korisno je obezbediti dodatnu obuku o zaštiti zaposlenim koji
dobiju svoje naloge, pregled pravila za pristup objektima IKT sistema i
eventualno potpisivanje Izjave o prihvatanju korisničkog naloga i
pridruženog pasvorda tipa, [9] »Ja dole potpisani priznajem da sam lično primio
pasvord/e za IKT sistem pridružene dole navedenim korisničkim nalozima. Shvatam i

- 487 -
prihvatam svoju odgovornost za zaštitu pasvorda i obavezujem se da sprovodim sve
primenjive standarde IKT zaštite i da nikome ne otkrivam pasvord/e. Dalje shvatam i
prihvatam da moram izvestiti koordinatora IKT zaštite o svakom problemu kojeg uočim
u korišćenju pasvorda ili kada imam razloge da verujem da je poverljivost mojih
pasvorda kompromitovana«. Pre potpisivanja korisnika i poĉetka perioda
vaţnosti, sva dokumenta zaštite treba da pregleda pravnik.

Kada se korisniĉki nalozi više ne koriste/zahtevaju, supervizor treba da

obavesti menadţera aplikacija i administratora sistema, tako da se nalozi
mogu blagovremeno ukinuti. Ovlašćenja za pristup mogu biti trajna, ili
privremena Administriranje pristupa i ovlašćenja je kontinualan proces:
novi korisniĉki nalozi se dodaju a stari brišu. Praćenje i aţuriranje
tragova promena aplikacija nije lako, ali je vaţno dopustiti korisnicima
pristup samo aplikacijama neophodnim za izvršavanje poslova. U
upravljanju korisniĉkim nalogom, treba uravnoteţiti zahteve za
efikasnost servisa i evidenciju relevantnih dogaĊaja, koja je neophodna
za upravljanja kompjuterskim incidentom i istragu kompjuterskog
kriminala. Centralizovano upravljanje procesom korisniĉkog pristupa
daje najbolje rezultate, ali je ĉesto decentralizovano, posebno za veće
IKT sisteme, gde se administratorima regionalnih i lokalnih RM
dodeljuju ovlašćenja da kreiraju naloge i menjaju korisniĉka ovlašćenja,
ili zahtevaju neophodne promene na centralizovanoj lokaciji.

Upravljanje korisniĉkim nalozima jedan je od kljuĉnih zadataka procesa

upravljanja personalnom zaštitom. Za ilustraciju razvijena je Vežba GIII
P3A, na primeru administracije korisniĉkih naloga i promene korisniĉkih
i administratorskih pasvorda u Windows XP OS.

- 488 -
2.2. Kontrola (auditing) prakse upravljanja korisniĉkim nalozima
Praksu upravljanja korisniĉkim nalozima potrebno je povremeno
kontrolisati na nivou aplikacija i IKT sistema.Treba proveravati nivoe
pristupa korisnika, koncept minimuma privilegija, aktivnost naloga,
aţurnost upravljaĉkih ovlašćenja, kompletnost obuke i.t.d. Kontrolu
mogu izvršiti, interni kontrolori, spoljni kontrolori ili specijalisti zaštite.
Dobra praksa je da menadţer aplikacija (vlasnik podataka) svaki mesec
kontroliše sve nivoe pristupa svih korisnika aplikacija i formalno izdaju
odobrenje za zvaniĉnu listu pristupa, što osoblje IKT sistema ne moţe
uvek izvršiti na najbolji naĉin. Menadţer aplikacija ĉesto jedini zna
tekuće zahteve za pristupe. Nezavisni auditor sistema zaštite moţe
detaljnije ispitati ovlašćenja za logiĉki i fiziĉki pristup.
2.3. Detekcija neovlašćenih/ilegalnih aktivnosti zaposlenih
Pored kontrole zaštite IKT sistema i analize kontrolnih tragova
postoji nekoliko mehanizama za detekciju nelegalnih aktivnosti. Na
primer, prevare koje zahtevaju fiziĉko prisustvo poĉinioca mogu se
otkriti na osnovu odsustva zaposlenog. Treba izbegavati stvaranje
prekomerne zavisnosti od pojedinaca, posebno u organizacijama drţavne
uprave i periodiĉno obnavljati bezbednosnu proveru zaposlenih, koja
moţe dati indikacije o mogućim ilegalnim aktivnostima i pretnjama za
IKT sistem i takva lica treba iskljuĉiti kao nepouzdana za rad u IKT
sistemu.
2.4. Privremena zamena i interni transferi zaposlenih
Znaĉajan aspekt upravljanja IKT sistemom ukljuĉuje aţurno
odrţavanje korisniĉkih ovlašćenja za pristup. Korisniĉka ovlašćenja
tipiĉno se menjaju u dva sluĉaja, [4]: promena posla, bilo privremena ili
stalna i otkaz sa posla iz bilo kojeg razloga.
Ĉesto se od korisnika zahteva da izvršavaju poslove izvan njihovog
delokruga rada u toku odsustva drugih zaposlenih. Ovo zahteva dodatna
ovlašćenja pristupa, koja se moraju izdavati propisno, paţljivo nadzirati i
biti konzistentna sa principom zajedniĉkog obavljanja posla. Ova se
ovlašćenja moraju brzo ukloniti kada se više ne koriste/zahtevaju.
Permanentne promene ĉesto su neophodne kada zaposleni menjaju radno
mesto u okviru organizacije. U ovom sluĉaju, obnavlja se proces davanja
ovlašćenja po nalogu i ukidanja ovlašćenja pristupa prethodnog lica,
zbog. moguće zloupotrebe, [7].

- 489 -
2.5. Ukidanje naloga

U opštem sluĉaju, ukidanje naloga korisnika i prava za pristup

objektima IKT sistema moţe se okarakterisati kao prijateljsko ili ne-
prijateljsko. Prijateljsko ukidanje naloga i pristupa je kada se zaposleni
dobrovoljno premešta, odbije da prihvati drugi poloţaj ili ode u penziju.
Ne-prijateljsko ukidanje je kada se zaposleni otpušta sa posla zbog viška
ili mimo njegove volje. Prva vrsta ukidanja naloga i prava pristupa
mnogo je ĉešća, ali se obe moraju razmatrati.

Prijateljski otkaz sa posla odnosi se na regularno udaljavanje zaposlenog

iz organizacije uz uzajamnu saglasnost, primenom standardnih procedura
za otpuštanje/transfer zaposlenih, koje ukljuĉuju blagovremeno ukidanje
naloga u IKT sistemu, potpisivanje dokumenta o otkazu, kontrolu
vraćanja kljuĉeva, knjiga iz biblioteke, regulisanje drugih ne-
informatiĉkih pitanja, kontrolu stanja dokumenata na hard disku,
skladištenja i bekapovanja. Zaposlenom treba dati instrukciju da li da
oĉisti raĉunar pre odlaska, ili ne. Ako je korišćena kriptozaštita, od
zaposlenog se moraju uzeti kriptografski kljuĉevi i odmah izmeniti, zatim
oduzeti smart kartice ili drugi autentifikacioni tokeni. Mora se razmatrati
i obaveza ĉuvanja poverljivosti podataka i informacija i proveriti da li je
zaposlenom potpuno jasno koje podatke i informacije moţe, a koje ne
moţe otkriti na novom radnom mestu.

Ne-prijateljsko otkazivanje posla protiv njegove volje i bez pristanka

zaposlenog, ukljuĉuje otkazivanje posla zbog ne-prijateljskog ponašanja
zaposlenog, otkaz zbog smanjenja radnih mesta i broja zaposlenih,
transfer protiv volje, otkaza zbog »sukoba liĉnosti«, ili iz bezbednosnih
razloga. Procedura ukljuĉuje sve aktivnosti kod dobrovoljnog otpuštanja
sa posla, s tim da je neka pitanja znatno teţe rešavati zbog potencijalne
nesaradnje ili opstrukcije otpuštenog. Najveća pretnja od ovakve vrste
otpuštanja zaposlenog dolaze od lica osposobljenih da izmene
programski kôd, modifikuju konfiguraciju sistema ili aplikacije ili na
drugi naĉin zloupotrebe IKT sistem. Korekcija ovih akcija moţe biti
zahtevna, skupa i dugotrajna. Preporuĉuje se ukidanje svih pristupa IKT
sistemu što je pre moguće, ako se priprema otpuštanje bez pristanka.

- 490 -
2.6. Personalna zaštita spoljnih saradnika po ugovoru

Saradnici pod ugovorom koji obavljaju poslove u IKT sistemu

obiĉno se angaţuju na kraći vremenski period od regularno zaposlenih,
što moţe uticati na rentabilnost bezbednosne zaštite. Angaţovanje ovih
lica podrazumeva odgovarajuću bezbednosnu proveru u zavisnosti od
osetljivosti mesta na koje se lice angaţuje.

2.7. Personalna zaštita u IKT sistemu sa javnim pristupom

U sistemima sa javnim pristupom, kao što su sistemi e-Uprave,

akademskih univerzitetskih mreţa i.t.d., nesmetan, efikasan i efektivan
javni pristup korisnika (organa drţavne uprave, graĊana i poslovnih
subjekata, studenata i drugih) glavni je funkcionalni zadatak IKT sistema.
GraĊani pristupaju sistemu e-Uprave radi dobijanja raznih informacija i
dokumenata, studenti bazama znanja i.t.d. U nekim sluĉajevima razmena
podataka i informacija je interaktivna izmeĊu sistema e-Uprave i drugih
subjekata. U opštem sluĉaju, kada su IKT sistemi namenjeni za javni
pristup, javljaju su dodatni bezbednosni problemi zbog: porasta pretnji,
teže administracije zaštite i težeg održavanja zahtevanog nivoa zaštite
informacija, [9].

Generalno, moţe se tvrditi da kada je neki sistem projektovan za javni

pristup, faktori rizika za taj sistem su veći, a ĉesto su veća ograniĉenja i
restrikcije za korišćenje objekata i servisa takvih sistema. Pored
povećanog rizika od hakerskih napada, IKT sistemi sa javnim pristupom
mogu biti predmet malicioznih aktivnosti iznutra sistema, na primer,
nezadovoljni zaposleni moţe uneti grešku (virus i sl.) u datoteke sistema
sa ciljem nanošenja štete, ili uništavanja podataka, programa i hardvera
sistema. Ovi napadi na sisteme sa javnim pristupom mogu imati znaĉajan
uticaj na reputaciju organizacije i poverenje klijenata/partnera/korisnika.
Drugi bezbednosni problemi mogu nastati zbog nenamernih grešaka
neobuĉenih korisnika. U IKT sistemima koji nemaju javni pristup,
postoje procedure za ukljuĉivanje korisnika u obuku, a ĉesto se zahteva i
potpisivanje izjava o odgovornosti korisnika u sistemu zaštite. Pored
toga, mogu se formirati profili korisnika, a sa sofisticiranim
mehanizmima kontrole mogu se otkriti neuobiĉajene aktivnosti korisnika.
U sistemima sa javnim pristupom korisnici su obiĉno anonimni, što
znaĉajno komplikuje administraciju sistema zaštite, [7].

- 491 -
3. MEĐUZAVISNOST SA PRIMARNIM SERVISIMA ZAŠTITE

Servis personalne zaštite preklapa se sa više drugih primarnih

servisa zaštite, kao što su: obuka i razvoj svesti o potrebi zaštite,
identifikacija, autentifikacija i kontrola pristupa i politika zaštite,
posebno njena komponenta usaglašenosti i kontrola pristupa, koja
zavisi od toga koliko dobro funkcionalni menadţer bira pravi tip i nivo
pristupa za zaposlene, informiše menadţera sistema o tipu i nivou
zahteva za pristup i o promenama u zahtevima za pristup.

Glavni troškovi personalne zaštite su za: bezbednosnu

proveru/pokrivanje, bezbednosnu obuku zaposlenih, administriranje
korisnika, administriranje pristupa i kontrolu.

- 492 -
4. REZIME

Personalna zaštita obuhvata popunu kadrova za rad u IKT sistemu

organizacije, administraciju korisnika koji rade sa objektima IKT
sistema, ukljuĉujući zabranu pristupa zaposlenih odreĊenim objektima
IKT sistema, kao i posebnu administraciju pristupa javnim servisima i
pristupa zaposlenih po ugovoru. Personalna zaštita usko je vezana sa
servisom logiĉke kontrole pristupa.

Proces popune radnih mesta u IKT sistemu generalno ukljuĉuje najmanje

ĉetiri koraka i moţe se primeniti na isti naĉin na opšte korisnike i
menadţere aplikacija, menadţere IKT sistema i specijaliste zaštite:
definisanje radnog mesta, ukljuĉujući razvoj i opis radnog mesta i
odgovornosti; odreĊivanje najvišeg nivoa osetljivosti informacija i drugih
IKT objekata kojima odreĊena lica mogu pristupiti; popuna radnih mesta,
ukljuĉujući razgovore, primenu bezbednosnih provera za sve zaposlene u
IKT sistemu i izbor zaposlenih i obuku.

Efektivno administriranje pristupa korisnika sistemu bitno je za

odrţavanje bezbednosti IKT sistema. Upravljanje korisničkim nalozima
obuhvata: identifikaciju, autentifikaciju, autorizaciju (ovlašćenja)
pristupa, kontrolu (auditing) i druge periodiĉne verifikacije legitimiteta
postojećih korisniĉkih naloga i ovlašćenja za pristup. Uvek postoji realna
potreba revizije i povremene modifikacije naloga ili ukidanja pristupa i
razmatranja drugih pitanja vezanih za lica koja daju ostavke, budu
unapreĊena na više radno mesto, dobiju otkaz ili se penzionišu.

Servis personalne zaštite preklapa se sa više drugih primarnih servisa

zaštite, kao što su:. obuka i podizanje svesti korisnika o potrebi zaštite,
identifikacija, autentifikacija, kontrola pristupa i politika zaštite.

Glavni troškovi personalne zaštite obuhvataju: bezbednosno pokrivanje

zaposlenih, bezbednosnu obuku zaposlenih, administriranje korisnika,
administriranje pristupa i proces kontrole.

- 493 -
5. KLJUĈNI TERMINI

Bezbednosna provera: pomaţe da se odredi da li je neko lice podobno

za odreĊeno radno mesto; dok bezbednosna provera ne bude završena,
zaposleni se ne mogu zvaniĉno rasporediti na radna mesta, niti imati
pristup osetljivim informacijama i objektima IKT sistema.
Minimalne privilegije: bezbednosni zahtev da se korisnicima daju samo
one vrste pristupa koje im trebaju za obavljanje poslova.
Osetljivost radnog mesta: nivo bezbednosne kritiĉnosti radnog mesta za
poslove organizacije, na osnovu kojeg odgovorni menadţer identifikuje
odgovarajuću i rentabilnu personalnu zaštitu.
Personalna zaštita: ukljuĉuje korisnike, projektante, specijaliste za
implementaciju, menadţere i administratore zaštite, kao i interakciju ovih
lica sa objektima IKT sistema, za dobijanje pristupa i ovlašćenja prava
pristupa koja su potrebna za obavljanje njihovih poslova; obuhvata i
popunu kadrova za rad u IKT sistemu organizacije.
Razdvajanje duţnosti: deljenje uloga i odgovornosti tako da ni jedan
pojedinac nije nezamenljiv i da ne moţe sabotirati kritiĉne procese.
Ukidanje naloga: korisnika i prava za pristup objektima IKT sistema
moţe biti prijateljsko ili sa pristankom korisnika i ne – prijateljsko, bez
pristanka korisnika.
Upravljanje korisniĉkim nalozima: ukljuĉuje podnošenje zahteva,
uspostavljanje, izdavanje i zatvaranje korisniĉkih naloga, zatim praćenje
korisnika i njihovih odnosnih prava za pristup i upravljanje ovim
funkcijama.

- 494 -
6. LITERATURA

1. American Bar Association Privacy & Computer Crime

Committee Section of Science & Technology Law, International
Startegy for Cyberspace Security, www.abapccc.com, august
2003.
2. Australian Communications-Electronic Security Instruction 33,
Security Handbook, www.acsi.com, 2002.
3. Carrol M.J., Computer Security, Butterworth-Heinemann, 1997.
4. David J. McKerrow, Canadian Handbook on Information
Technology Security, www.canadacss.com, 1999.
5. IEC/ISO 17799 Security Standard overview,
http://www.securityauditor.net/iso17799/what.htm, 2005.
6. IT Baseline Protection Manual, http://www.bsi.bund.de/gshb,
juli 2000.
7. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
8. NIST SP 800-12, An Introduction to Computer Security: The
NIST Handbook, http://www.nist.gov/publications,, verzija 2004.
9. Purser S., A practical Guide to Managing Information Security,
Artech House, Boston-London, www.artechhouse.com, 2004.
10. Russel D., Gangemi G.T. sr, Computer Security Basics, O‘Reilly
and Ass., SAD, 1992.

- 495 -
4. UPRAVLJANJE FIZIĈKO TEHNIĈKOM ZAŠTITOM

0. UVOD

Po završetku ovog poglavlja razumećete:

- standard fizičke zaštite za računarsku sobu i rdnu stanicu

- značaj fizičke zaštite u sistemu IKT zaštite
- pretnje i mere fizičke zaštite
- specifičnosti zaštite EM i optičkih medija
- trend konvergencije fizičke i logičke kontrole pristupa

Fiziĉka zaštita i zaštita okruţenja IKT sistema treba da se

zasnivaju na standardima i principima dobre prakse fiziĉke zaštite
znaĉajnih objekata, koja obuhvata fiziĉko obezbeĊenje, tehniĉku zaštitu -
video nadzor, protivpoţarnu (PPZ) i protivprovalnu zaštitu.

U pristupu fiziĉkoj zaštiti treba primenjivati standardne principe fiziĉke

zaštite kao što su: zaštita po dubini, planiranje lokacije, akomodacija,
redovan nadzor i revizija zaštite, zaštita zaposlenih i klijenata;
upravljanje vanrednim dogaĊajem; fiziĉka zaštita klasifikovanih
informacija i fiziĉkih objekata IKT sistema (procena rizika, plan zaštite
lokacije, odgovornost za uspostavljanje odgovarajućeg okruţenja-
restriktivne zone); fiziĉka zaštita raĉunarske opreme konzistentna zaštiti
papirnih informacija i zaštita medija za masivno skladištenje, koje
zahtevaju posebne fiziĉke mere zaštite, jer fiziĉka zaštita tvrdih kopija i
pokretnih medija nije direktno primenljiva za fiziĉku zaštitu raĉunarskih
sistema.

- 496 -
1. STANDARDI FIZIĈKE ZAŠTITE
1.1. Standardi fiziĉke zaštite za raĉunarsku sobu i radne stanice
U procesu upravljanja fiziĉkom zaštitom treba koristiti
raspoloţive nacionalne standarde za fiziĉku zaštitu znaĉajnih objekata,
fiziĉku zaštitu raĉunarske sobe i radne stanice, koje izdaje nacionalno
telo za standardizaciju. Ovi standardi obuhvataju fiziĉku zaštitu
klasifikovanih i neklasifikovanih objekata. Klasifikovani objekti sadrţe
restriktivne zone, a neklasifikovani su javno dostupni. Klasifikovani
standardi ukljuĉuju znaĉajniju protivpoţarnu zaštitu (PPZ).
Standardi za fiziĉku zaštitu radnih stanica obiĉno su ukljuĉeni u
standarde raĉunarske sobe, a stepen mera fiziĉke zaštite gradira se obiĉno
u 4 nivoa od najvišeg (4) do najniţeg nivoa (1). Na primeru australijskog
standarda raĉunarske sobe i radne stanice opisani su nivoi 4. stepena (RS
4 i RSt4) fiziĉke zaštite u PRILOGU III 4A, [1].
Zaštita fiziĉke infrastrukture je od presudnog znaĉaja za sistem IKT
zaštite u celini i ĉini bazu na kojoj se izgraĊuje zaštita IKT sistema OSI
modela arhitekture, što je ilustrovano na Sl. 1.1., [9].

Sl.1.1. Mesto sistema zaštite fiziĉke infrastrukture IKT i okruţenja,

[9]

- 497 -
2. FIZIĈKA ZAŠTITA IKT SISTEMA I ZAŠTITA OKRUŢENJA

2.1. Rizici proboja fiziĉke zaštite i zaštite okruţenja IKT sistema

Termin fizička zaštita i zaštita okruženja IKT sistema odnosi se na

mere i metode fiziĉke zaštite objekata IKT sistema, zgrada i
infrastrukture okruţenja za podršku rada IKT sistema, od sluĉajnih ili
namernih pretnji, a ukljuĉuje sledeće tri kljuĉne oblasti, [8]:

1. Fizički objekti zgrade, druge fiksne graĊevinske strukture ili

vozila u kojima su smešteni IKT sistemi i/ili komponente
raĉunarske mreţe. Fiziĉke karakteristike ovih struktura odreĊuju
nivo pretnji od poţara, poplave, ili neovlašćen fiziĉki pristupa.
2. Operativna lokacija odreĊuje: prostorne karakteristike prirodnih
pretnji (zemljotres, poplava i dr.); humane pretnje (provale,
neredi, intercepcija signala, snimanje kompromitujućeg EM
zraĉenja (KEMZ), [7], [5]) i sekundarna oštećenja, (izlivanje
toksiĉnih kemikalija, eksplozija, vatra i EM interferencije jakih
emitera, n.p.r. radara).
3. Okruženje IKT sistema ĉine tehniĉki objekti, tehniĉki i ljudski
servisi za podršku rada IKT sistema (napajanje, grejanje i
hlaĊenje i telekomunikacije), ĉiji nestandardan moţe izazvati
prekid rada IKT sistema, oštećenja hardvera ili podataka.

Fiziĉka zaštita IKT sistema i okruţenja obezbeĊuje i zaštitu zaposlenih, a

teţišno je usmerena na zaštitu IKT sistema od sledećih pretnji:

Prekid davanja servisa (DoS) moţe izazvati neka spoljna pretnja, a

veliĉina gubitaka zavisi od trajanja prekida servisa sistema, karakteristika
operacija i korisniĉkih akcija.
Fizička oštećenja ili uništenje hardvera i softvera IKT sistema mogu se
popraviti ili zameniti. Veliĉina gubitka od fiziĉkog oštećenja zavisi od
cene popravke ili zamene oštećenog ili uništenog hardvera, softvera ili
podataka, kao i od troškova koji nastaju zbog prekida servisa.
Neovlašćeno otkrivanje informacija mogu omogućiti fiziĉke ranjivosti
prostorija u kojima su smešteni IKT sistemi, što je još opasnije u visoko
distribuiranom mreţnom okruţenju.
Gubitak kontrole integriteta IKT sistema moţe izazvati napadaĉ koji
dobije fiziĉki pristup CPU serverskog sistema ili neovlašćen pristup PC
raĉunaru. Posledice mogu biti kraĊa i prekid servisa, otkrivanje

- 498 -
informacija, pronevera, izmene sistemskih i aplikativnih programa,
unošenje Trojanskih konja i drugih malicioznih kodova, a teško je
odrediti šta je modifikovano, izbrisano ili korumpirano. Znaĉajni su
troškovi zamene ukradenog hardvera i restauracije podataka
uskladištenih na ukradenim medijima, a troškovi otkrivanja osetljivih
informacija mogu biti nepredvidljivo veliki.

2.2. Fiziĉka zaštita IKT sistema i okruţenja

Fiziĉka zaštita IKT sistema i okruţenja obuhvata kontrolu fiziĉkog

pristupa perimetra i ulaza u zgradu i u restriktivne prostore u zgradi,
proces fiziĉkog oznaĉavanja zaposlenih (bedţevi, kartice), podsisteme za
grejanje, hlaĊenje i ventilaciju, PPZ, video nadzor, protivprovalnu
zaštitu, zaštitu elektronskih medija i komunikacija. Mere fiziĉke zaštite
IKT sistema i okruţenja primenjuju se u osam glavnih oblasti, [8]:

1. barijere za fiziĉki pristup,

2. protiv poţarna zaštita (PPZ),
3. sistemi za grejanje, hlaĊenje i ventilaciju,
4. kolaps fiziĉke strukture,
5. vodovodne instalacije,
6. prisluškivanje podataka,
7. uticaj elektromagnetnih (EM) smetnji i
8. mobilni ili prenosni IKT sistemi.

Barijere za fizički pristup ograniĉavaju ulaz/izlaz personala, opreme i

medija u/iz neke zone, kao što je zgrada, kancelarija, raĉunarski centar,
serverska soba i dr., a ukljuĉuju restriktivne prostore, barijere za opštu
izolaciju svakoj zoni, ulazne taĉke u barijeri i mere zaštite svake od
ulaznih taĉaka. Zaposleni restriktivnim prostorima igraju vaţnu ulogu u
fiziĉkoj zaštiti IKT sistema, jer su obuĉeni da ispitaju i kontrolišu sva
nepoznata lica. Barijere za fiziĉki pristup štite zone sa objektima IKT
sistema, lokacije kabliranja, servise napajanja elektriĉnom energijom,
rashladne sisteme, sisteme za grejanje, telefonske linije i linije za prenos
podataka, prostorije sa rezervnim kopijama izvornih programa i podataka
i izvornih dokumenata, kao i druge elemente potrebne za rad IKT
sistema. Ovo praktiĉno znaĉi da su restriktivne sve prostorije i zone u
zgradi, koje sadrţe objekte IKT sistema.

- 499 -
Bezbednosni ciljevi barijera za fiziĉki pristup u konfliktu su sa zahtevima
za fiziĉke izlaze u sluĉaju ţivotne opasnosti i vanrednim dogaĊajima.
Generalno, prednost treba dati izlazima u sluĉaju opasnosti, ali je moguće
izbalansirati ciljeve oba zahteva (npr., opremiti vrata za hitne izlaze sa
vremenskim kašnjenjem od trenutka pritiskanja ruĉice za uzbunjivanje i
oglašavanja alarmne sirene).

Postoji više vrsta barijera za fiziĉki pristup, ukljuĉujući bedţeve,

memorijske kartice, fiziĉko obezbeĊenje (ĉuvare), kljuĉeve, pokretna
vrata, ograde i vrata sa šifrovanom blokadom. Treba analizirati
efektivnost barijera za fiziĉki pristup u toku radnog vremena i u vanradno
vreme, kao i izvodljivost tajnog ulaska zaobilaţenjem ili probojem
barijera. Efektivnost zavisi od karakteristika, implementacije i
funkcionisanja barijera. Dodavanjem dodatnih barijera iza osnovnih
moţe se smanjiti rizik neovlašćenog ulaska u zone iza barijera. Fiziĉke
modifikacije barijera mogu redukovati ranjivosti na tajne ulaske.
Protivprovalni detektori, video nadzor, detektori kretanja i drugi senzori
mogu detektovati ulaske u restriktivne prostore.

Protiv-požarna zaštita (PPZ) u zgradi posebno je znaĉajna za bezbednost

IKT sistema zbog potencijalnog uništenja hardvera, softvera i podataka,
rizika za ljudske ţivote i druge štete od poţara. Faktori rizika od poţara u
zgradi koja sadrţi vaţne objekte IKT sistema su, [7]:

Izvori požara su materije koje emituju dovoljnu toplotu koja moţe

izazvati paljenje drugih materijala: kvarovi elektriĉnih instalacija,
nemarno odbaĉena neugašena cigareta, nepropisan rad sa grejalicama i
drugim ureĊajima za zagrevanje, nepropisno skladištenje lako zapaljivih
materijala i podmetnuti poţari.
Izvori goriva i kiseonik moraju postojati za odrţavanje i rasplamsavanje
poţara. Više sagorivog materijala po kvadratnom metru, znaĉi veći poţar
i veću štetu.
Ispravno održavanja zgrade, posebno PPZ sistema, minimizira
akumulaciju sagorivog materijala, a time i rizik od izbijanja poţara.
Sadržaj zgrade sa iznad-proseĉnim brojem potencijalnih izvora poţara
(npr., skladište lako zapaljivih materijala) inherentno je opasniji od
drugih sadrţaja.
Detektori požara, što su brţi, a sve ostalo jednako, lakše će se i brţe
ugasiti poţar i smanjiti ukupna šteta. Vrlo je vaţno precizno odrediti
mesto izbijanja poţara.

- 500 -
PPZ aparati za gašenje vatre mogu biti automatski (npr. raspršivaĉi
vode), ili poluautomatski (npr. klasiĉni pokretni PPZ aparati). Propisno
instalirani i odrţavani, automatski raspršivaĉi su veoma efektivni u PPZ,
a postoje dva tipa: suvi tip - nema vode ni pritiska vode u mlaznicama,
pre otvaranja kontrolnog ventila na signal javljaĉa poţara i vlažni tip -
stalno pod pritiskom vode i lako se aktivira laţnim alarmima ili
kvarom/oštećenjem glava mlaznica. Automatski raspršivaĉi redukuju
štetu od poţara, ali zahtevaju opremu za brzo izbacivanje vode za gašenje
poţara, da bi se smanjila šteta od vode.
Kvarovi tehničkih ureĎaja za obezbeĎenje radnog okruženja IKT
sistema smanjuju tehniĉku pouzdanost tih sistema. UreĊaji za zaštitu
radnog okruţenja moraju funkcionisati propisno. Kvarovi sistema za
grejanje i hlaĊenje, obiĉno izazivaju prekid servisa IKT sistema i mogu
oštetiti hardver. Korišćenjem faktora MTBF (srednje vreme izmeĊu
otkaza) i MTBR (srednje vreme izmeĊu popravki-remonta) za elektriĉnu
centralu, toplanu za centralno grejanje, pumpnu stanicu za snabdevanje
vodom, kanalizaciju i druge pomoćne sisteme za rad IKT sistema i
konfor radnog osoblja odreĊuje se tehnička pouzdanost tih sistema,
parametri pretnji oĉekivanih kvarova i izraĉunava ukupan rizik. Rizik se
moţe smanjiti zamenom jedinica ureĊaja sa niţim MTBF vrednostima.
MTBR se moţe smanjiti instalacijom redundantnih sistema,
skladištenjem rezervnih delova i obukom osoblja za odrţavanje sistema.
U PRAKTIKUMU data je Vežba III 4V1 za proraĉun raspoloţivosti u
funkciji tehniĉke pouzdanosti sistema, [7].

Kolaps strukture zgrade uobiĉajeno nastaje zbog zemljotresa, sneţne

lavine, klizišta, eksplozije ili poţara koji oslabe mehaniĉku strukturu
zgrade. Ovakve pretnje primenjive su pre svega na visoke zgrade i one sa
velikim internim prostorom bez nosećih stubova.

Kvarovi vodovodnih instalacija ne dešavaju se ĉesto, ali mogu biti

veoma razorni. Plan zgrade pomaţe da se lociraju vodovodne instalacije
riziĉne za hardver IKT sistema. Lokacija sigurnosnih ventila i procedure
za njihovo korišćenje u sluĉaju kvara moraju biti precizno specificirane i
na trenutnom raspolaganju u sluĉaju vanrednog dogaĊaja.

Prisluškivanje podataka, zavisno od tipa podataka i procesa IKT

sistema, moţe nositi znaĉajan rizik. Postoje tri naĉina presretanja
(intercepcije) podataka u IKT sistemu:

- 501 -
Direktno osmatranje ekrana radnih stanica IKT sistema i terminala od
strane neovlašćenih lica u većini sluĉajeva lako je spreĉiti premeštanjem
monitora i izbegavanjem ovakvih pretnji.
Intercepcija transmisije podataka moţe biti pretnja, ako napadaĉ ima
pristup prenosnim linijama. Napadaĉ moţe prisluškivati (u aktivnom ili
pasivnom reţimu) fiziĉke linije lokalne mreţe i ĉitati prenosne podatke,
ili hvatati pakete podataka alatima za monitorisanje mreţe. Kod beţiĉnih
mreţa (WLAN), gde je zraĉenje prenosnih podataka namenska funkcija,
mogućnost intercepcije se povećava.

Elektromagnetska intercepcija koristi parazitno ili kompromitujuće

zraĉenje EM energije –KEMZ, koje emituju kondukcijom i radijacijom
svi ureĊaji i mreţne instalacije IKT sistema u aktivnom radu. Ovo
zraĉenje moţe se detektovati sa specijalnim, namenskim prijemnicima i
antenskim sistemom. Uspešna intercepcija zavisiće od snage signala,
osetljivosti i lokacije prijemnika i antenskog sistema. Što je veće
rastojanje izmeĊu IKT sistema i KEMZ prijemnika to je manja
mogućnost uspeha intercepcije. Tehnologija za EM intercepciju KEMZ
signala naziva se TEMPEST (Transient Elektro-Magnetic Pulse
Surveillance Technology), kao i standard za zaštitu od KEMZ-a -
TEMPEST (Transient Elektro Magnetic Pulse Emanating Standard), koji
definiše oklapanje ureĊaja, ili celokupne opreme u kompjuterskoj sobi i
druge naĉine smanjenja širenja KEMZ signala, [3], [4], [5]. Odnos
signal/šum na prijemnoj strani, delom odreĊen brojem konkurentnih
emitera, takoĊe utiĉe na uspeh intercepcije. Više IKT radnih stanica
istog tipa na istoj lokaciji koje izvršavaju »sluĉajne« aktivnosti, takoĊe
smanjuju uspeh intercepcije KEMZa odreĊene radne stanice, bez obzira
što svaka radna stanica i svaki ureĊaj imaju specifiĉan »elektronski
otisak«. TEMPEST otporne raĉunare i perifernu oprema (štampaĉe,
skenere, drajvere, trake, miševe i.t.d.) upotrebljavaju drţavne
organizacije i organizacije koje po ugovoru rade za njih, da bi spreĉile
monitorisanja podataka putem KEMZA. Zaštita od TEMPEST napada
obiĉno se obezbeĊuje oklapanjem ureĊaja, prostorija, ili ĉitavih zgrada
bakrom ili drugim provodnim materijalom, [7].

- 502 -
EM interferencija moţe, takoĊe, predstavljati rizik za komponente
zaštite i IKT sistema. Tipovi spoljnih EM interferencija su:

a. EM indukcija (EMC) primarno se odnosi na munje koje mogu na

bilo kojoj energetskoj ili komunikacionoj liniji izazvati
potencijalno opasnu indukciju EM energije i poţar.
b. Statičko pražnjenje moţe prouzrokovati energetsko
preopterećenje, oštetiti ĉipove i štampana kola i usporiti kretanja
mehaniĉkih delova, ĉak i ispod nivoa detekcije.
c. EM interferencije (EMI) spoljnih izvora elektriĉne emisije,
namernog ili sluĉajnog porekla, mogu prouzrokovati brisanje
podataka, korupciju datoteka i blokirati rad lokalne IKT opreme.
d. Radio-frekvencijska interferencija (RFI) moţe prouzrokovati
korupciju i brisanje podataka, i oštećenja IKT opreme, koja ne
moţe prepoznati da li je komanda došla iz legitimnog izvora.

Mobilni i prenosni sistemi instalirani u vozilu ili prenosni (Lap Top,

Noutbook), obiĉno zahtevaju modifikaciju analize i upravljanja rizikom.
Raĉunarski sistem u vozilu deli iste rizike kao i samo vozilo, ukljuĉujući
udese i kraĊu, kao i regionalne i lokalne faktore rizika. Portabl sistemi
imaju veći rizik od kraĊe i fiziĉkog oštećenja, a osetljive ili vaţne
podatke treba uskladištiti na pokretni medij ili šifrovati. Dodatnu zaštitu
obezbeĊuju hardverski i/ili softverski ureĊaji za kontrolu pristupa.

- 503 -
2.3. Zaštita EM i optiĉkih medija

Generalno, postoji oprema koja moţe kompletno ukloniti sve

magnetske tragove sa EM medija koji se odlaţu, ukljuĉujući RAM
memorije. MeĊutim, neke manje detaljne mere saniranja medija mogu
znaĉajno redukovati rizik od izvlaĉenja podataka i informacija iz
korišćenih medija. Pri tome treba razlikovati procese saniranja od
deklasifikacije medija, [1]:

Saniranje je proces brisanja što je moguće više podataka sa medija ili

kompjuterske opreme, koji ne uništava i ne menja automatski
klasifikaciju medija/opreme.

Deklasifikacija je uklanjanje ili redukcija nivoa klasifikacije

medija/opreme na bazi procene rizika, odluke o nepropisnom otkrivanju
preostalih podataka u medijima/opremi i procene ugovornih obaveza i
eventualne prodaje, odlaganja i popravke opreme. Mediji/oprema koji
nose klasifikovane podatke, moraju imati oznaku najvećeg stepena
klasifikacije podataka, dok se ne izvrši propisano saniranje ili
deklasifikacija. Deklasifikacija magnetskih medija vrši se
demagnetizacijom i višestrukim presnimavanjem.

Demagnetizacija smanjuje gustinu magnetskog fluksa primenom

reverznog magnetnog polja i obezbeĊuje neĉitljivost prethodno
snimljenih podataka i informacija.

Višekratno presnimavanje magnetskih medija uzastopnim binarnim „1― i

„0― standardno se koristi za efikasno brisanje podataka. Ciklus se
ponavlja više puta, zavisno od procenjenog rizika ili zahteva za
deklasifikaciju, a preporuĉuju se sledeći koraci:

1. presnimiti sve lokacije bita podataka sa binarnom „0― i proveriti

uspeh,
2. presnimiti sve lokacije bita podataka sa binarnom „1― i proveri
uspeh i
3. ponoviti 1. i 2. korak više puta prema zahtevu za deklasifikaciju
ili proceni rizika.

- 504 -
Nepotpuno izbrisani i neispravno klasifikovani mediji/ureĊaji koji se ne
mogu sanirati demagnetizacijom i višestrukim presnimavanjem, moraju
se uništiti.

Laserski štampači i kopir aparati mogu se sanirati i deklasifikovati

štampanjem ĉistih (praznih) kopija nakon poslednjeg štampanja
klasifikovanih podataka i informacija.

Memorijski čipovi i drugi elementi za skladištenje saniraju se ili

deklasifikuju na bazi procene rizika, uklanjanjem izvora napajanja i
uzemljivanjem memorijskih elemenata.

Procedura zaštite EM i optičkih medija koji se koriste u IKT sistemima

drţavnih organa treba da specifiĉno obuhvati: mere zaštite od otkrivanja
poverljivih informacija sa odloţenih, neispravnih ili zastarelih
medija/opreme i fiziĉku zaštitu korišćenih arhiviranih, uskladištenih
medija.

2.3.1. Metodi fizičke zaštite i uništavanja medija

Destrukcija ĉvrstih diskova i memorija vrši se topljenjem,

lomljenjem ili mlevenjem po odobrenom metodu. Svi mediji za
skladištenje klasifikovanih podataka i informacija moraju se fiziĉki
ĉuvati prema standardima i Uputstvu za zaštitu organizacije.

Gradacija stepena saniranja medija nije konaĉna, nego više uputstvo za

rad. Generalno je najĉešća podela medija u tri kategorije: magnetski,
laserski štampači/ kopir mašine i osetljive memorije, koje ukljuĉuju
ĉvrste (npr. RAM) gde se podaci gube kada se iskljuĉi napajanje, ali ne
ukljuĉuju elemente koje ne gube podatke (EEPROM, npr.).

Standarda preporuĉuje ĉetiri nivoa saniranja medija (Tabela 2.1), pri

ĉemu 0. nivo oznaĉava da ni jedna kategorija medija nije sanirana [1]:

- 505 -
Nivo Stepen saniranja medija

Magnetski mediji su sanirani propisanom demagnetizacijom ili

1. presnimavanjem.
Laserski štampač/kopir nije saniran.
Osetljiva memorija nije sanirana.
Magnetski mediji su sanirani propisanom demagnetizacijom ili 2-3-
strukim presnimavanjem u skladu sa procenom rizika (uzimajući u
obzir cenu medija ili cenu prodaje, količinu podataka i informacija i
2. mogućnost popravke). Nivo deklasifikacije mora biti barem dva nivoa
niži od originalne.
Laserski štampač/kopir je saniran prema propisanom metodu.
Osetljiva memorija je sanirana prema propisanom metodu
Svi magnetski mediji su uništeni.
Laserski štampač/kopir je saniran prema propisanom metodu.
3. Osetljiva memorija je sanirana prema propisanom metodu na osnovu
procene rizika, uzimajući u obzir cenu medija ili prodaje, količinu
podataka i informacija i mogućnost popravke
Svi magnetski mediji uništeni.
4. Svi laserski štampači/kopiri uništeni.
Sve osetljive memorije uništene.

T.2.1. Standard stepena saniranja kljuĉnih kategorija medija

- 506 -
2.4. Metod implementacije fiziĉke zaštite

Sistem fizičke zaštite kontroliše ko ima pravo pristupa objektima i

zgradama organizacije, u kojem vremenskom periodu i pod kojim
uslovima. Fiziĉke i mere zaštite okruţenja biraju se i implementiraju zato
što su efektivne i rentabilne, na osnovu ĉetiri opšta kriterijuma za izbor
mera zaštite, [2]:
1. Mere zaštite se zahtevaju prema zakonu i regulativi (primer:
vrata za izlaz u vanrednim prilikama sa alarmnim prekidaĉem i
izlaznim osvetljenjem).
2. Troškovi su beznačajni, ali je korist materijalna (primer: objekti
IKT sistema ĉuvani u restriktivnom prostoru sa vratima kroz koja
se retko prolazi).
3. Zaštita IKT sistema sprečava potencijalno fatalna izlaganja
sistema, ali ima ozbiljne troškove (primer: bekapovanje
programa i podataka).
4. Procenjuje se da je mera IKT zaštite rentabilna (primer: ako su
troškovi potencijalne zaštite znaĉajni i ne mogu se opravdati ni sa
jednim od prva tri razloga, kao u sluĉaju prekida elektriĉnog
napajanja i mera zaštite. Dva sistema mogu imati istovetnu
pretnju od kvara električnog napajanja i iste parametre
ranjivosti, ali i potpuno različite parametre potencijalnih
gubitaka. Na raspolaganju je veći broj mera zaštite razliĉitih po
ceni i performansama. Nabavke UPS jedinice zavisi od veliĉine
elektriĉnog opterećenja, broja minuta rada i brzine reagovanja na
prekid napajanja, a moţe se instalirati neki generator za kraće
prekide napajanja ili kao dugotrajni rezervni izvor napajanja za
UPS sistem. Odluka o izboru rešenja zavisi od veliĉine
opterećenja, koliĉine i kapaciteta snabdevanja gorivom na lokaciji
i brzine prekidaĉa za prebacivanje sa mreţnog na generatorsko
napajanje.
Savremeno rešenje sistema fiziĉke zaštite ĉini integrisana fizička
infrastruktura okruţenja IKT sistema, koja obuhvata sledeće
komponente, [9]:
– sistem neprekidnog napajanja sa distribucijom,
– sistem klimatizacije sa distribucijom hladnog vazduha,
– sistem senzora za nadzor okruţenja IS,
– jedinstvenu platformu za upravljanje i monitoring.

- 507 -
Sistem neprekidnog napajanja sa distribucijom ima sledeće
karakteristike: modularnost, skalabilnost, visoku raspoloživost
(redundantnost), visoku tehničku pouzdanost, zaštićeno napajanje od
parazitnog EM zračenja (KEMZ), standardizovane dimenzije za IKT
opremu i visoku upravljivost.

Sistem klimatizacije sa distribucijom hladnog vazduha, koji ne hladi

prostor već samo objekte i mesta gde se disipira toplota, ima sledeće
karakteristike: prilagoĎen je rekovima sa opremom koja ima veliku
gustinu disipacije toplote, prilagoĎen je novim tipovima servera i druge
IKT opreme, ima jedinstveno upravljanje koje sprečava konflikt izmeĎu
rashladnih jedinica i integrisan je u IKT sistem.

Sistem senzora za nadzor okruženja IS kontroliše fiziĉki pristup,

temperaturu i vlaţnost vazduha, strujanje vazduha, taĉku kondenzacije,
opasne gasove, curenje vode, pojavu dima, buku, skladištenje podataka i
vrši rano upozoravanje putem e-pošte, mobilnog telefona i pejdţera.

Jedinstvena platforma za upravljanje i monitoring ima pretraţivaĉ

(browser), analizira trendove stanja u više rekova, ima fleksibilnu
grafiĉku prezentaciju izlaznih rezultata u razliĉitim formama pogodnim
za brzo odluĉivanje i reagovanje.

- 508 -
3. KONVERGENCIJA FIZIĈKE I LOGIĈKE KONTROLE
PRISTUPA

U većini organizacija, sistemi logiĉke i fiziĉke kontrole pristupa

funkcionišu kao dve odvojene decentralizovano upravljane celine.
Logiĉkom kontrolom pristupa objektima IKT sistema upravlja
informatiĉko odeljenje organizacije, a fiziĉkom obiĉno opšta sluţbe ili
sluţbe fiziĉkog obezbeĊenja organizacije.

S obzirom na tehnološku integraciju sistema zaštite u mnogim oblastima:

kartiĉna kontakno-beskontaktna kontrola pristupa zgradi, liftu, raĉunaru,
bazi podataka, restriktivnom prostoru; video nadzora i raĉunarske druge
tehnologije; PPZ i protivprovalnih senzora, video nadzora i drugih
tehnologija, opravdano je oĉekivati konvergenciju logiĉke i fiziĉke
zaštita u integrisani sistem za logiĉko-fiziĉku kontrolu pristup, [7].

Koncept upravljanja identitetom, koji se moţe definisati kao „skup

procesa, alata i servisa koji omogućavaju bezbedan pristup velikom
skupu sistema, servisa i aplikacija sistema―, kljuĉna je komponenta za
upravljanje uticajem okruţenja na IKT sistem, a odnosi se na
administriranje naloga za pristupe sistemima i aplikacijama, [6]. Sistem
za upravljanje identitetom, primarni gradivni blok zaštite IKT sistema,
sadrţi sledeće interaktivne elemente:

1. Jedinicu za skladištenje podataka, logiĉki repozitorij i struktura

modela podataka, ĉesto implementirana u formi direktorijuma,
koji sadrţi informacije iz politike zaštite i podatke o pravima
pristupa korisnika.
2. Jedinicu za autentifikaciju, korisnika ili verifikaciju identiteta
koji je pridruţen datom korisniku, ukljuĉuje pasvord,
biometrijski sistem autentifikacije ili standardne X.509 PKI
sertifikate za digitalni potpis.
3. Kontrole politike zaštite koje definišu ko ima pristup, kojim
informacijama i pod kojim uslovima.
4. Jedinica za kontrolu (auditing) koja prati i registruje tragove
toka informacija kada se podaci registruju, koriste i menjaju.

- 509 -
Sve navedene komponente interaktivno deluju u sistemu za upravljanje
identitetom u cilju obezbeĊenja:

 jednokratne identifikacije korisnika za primarnu autentifikaciju,

 personalizacije, koja pridruţuje neku aplikaciju i informaciju nekom
identitetu i
 upravljanja pravima pristupa koje omogućava aplikacijama da izvrše
autorizaciju na bazi informacija iz politike zaštite i datih privilegija.

Jedinstveni mehanizam za upravljanje identifikatorima preko sistema za

upravljanje identitetom moţe ublaţiti problem gubitka i resetiranja
lozinki i prava pristupa.

Servisi fiziĉke zaštite deluju interaktivno sa logiĉkim servisima u brojnim

primerima koji ukazuju na potrebu integracije kontrola fizičkog i
logičkog pristupa: ĉitaĉ fiziĉkog pristupa povezan sa PPZ sistemom, koji
ga deblokira u sluĉaju poţara; ĉitaĉ fiziĉkog pristupa povezan sa
sistemom za video nadzor, kojeg monitoriše fiziĉko obezbeĊenje,
odgovorno za zaštitu opšte imovine organizacije i zaposlenih od vidljivih
pretnji, monitorisanje i upravljanje protokom ljudi i opreme kroz fiziĉke
objekte organizacije, upravljanje metodama pristupa, kontrolu proboja
perimetra i zauzetosti prostorija.

3.1. Integracija kontrola fiziĉkog i logiĉkog pristupa

Savremene kombinovane pretnje sa elementima terorizma,

zahtevaju celovit pristup problematici zaštite - od fiziĉke do zaštite
kibernetiĉkog prostora. Kombinacija logiĉke i zaštite fiziĉkog pristupa
daje mnogo obuhvatniji pogled na potencijalne pretnje iz okruţenja.

Razlozi za konvergenciju ova dva sistema, koju obezbeĊuje PKI

tehnologija i sistem smart kartica/tokena, brojni su: smanjenje ukupnih
troškova zaštite, generisanjem jedinstvene smart kartice za pristupe svim
fiziĉkim i informacionim objektima, zavisno od ovlašćenja, bez obzira na
lokaciju; efikasnija kontrola pristupa i centralizovana evidencija povreda
sistema zaštite, što je od ogromnog znaĉaja za digitalnu forenziĉku
analizu, istragu i veštaĉenje kompjuterskog kriminala; izvršavanje
funkcija nadzora u realnom vremenu, korišćenjem centralizovanog
repozitorija podataka (primer: kada napadaĉ unese korisniĉko ime i
lozinku u zaštićeni server, a ime vlasnika nije logovano na ulazu u

- 510 -
zgradu, aktivira se alarm za fiziĉku kontrolu pristupa); korišćenje
jedinstvenog procesa i lokacije za izdavanje fiziĉkih identifikatora (n.p.r.
bedţevi) i parametara za logiĉki identitet (n.p.r. biometrijskih – otiska
prsta i sl) uz neznatno povećanje troškova i dr.

Da bi do ove konvergencije došlo, upravljanje integralnim sistemom

zaštitom mora integrisati postojeće procese upravljanja fiziĉkom zaštitom
objekata, personalom zaštitom i zaštitom IKT sistema organizacije.
Ovakav pristup zahteva jasno definisanje vlasništva nad objektima
organizacije i objektima IKT sistema u organizaciji, kao i odgovornosti u
brojnim procesima upravljanja, ka što su: definisanje politike zaštite na
nivou organizacije, obezbeĊenje zaštite korisnika i upravljanje opštom
imovinom, nadzor i kontrola sistema zaštite, odgovor na kompjuterski
incident i planiranje vanrednih dogaĊaja i kontinuiteta poslovanja
organizacije. Oĉigledno, kljuĉni faktor konvergencije sistema fiziĉke i
logiĉke kontrole pristupa postaje tehnologija, jer omogućava integraciju
svih procesa u kojima moţe redukovati pretnje za specifiĉne ranjivosti.
Na Sl.3.1 prikazan je model odnosa fiziĉke i logiĉke kontrole pristupa sa
procesima upravljanja sistemom bezbednosti i zaštite organizacije.

Upravljanje Upravljanje Nadzor i kontrola Upravljanje

Politika zaštite
identitetom pristupom sistema zaštite incidentom

FIZIČKA ZAŠTITA ZAŠTITA IKT SISTEMA

Izdavanje i opoziv Upravljanje korisničkim

kartica nalozima

Upravljanje
Nadzor ureĎaja za
ranjivostima i
kontrolu pristupa
antivirusna zaštita

Upravljanje validacijom Bekapovanje i

pristupa oporavak

Upravljanje ţurnalima IDS/IPS i barijere

Procedura pristupa u
VPN
hitnim slučajevima

Sl.3.1. Model odnosa logiĉke i fiziĉke kontrole pristupa, [7]

- 511 -
Za integraciju fiziĉke zaštite i zaštite IKT sistema potrebno je imati
jedinstven identifikator (token). Savremene višenamenske smart kartice
sa ugraĊenim mikrokontrolerom, logiĉan je izbor takvog tokena, koji
postaje integrator fiziĉke zaštite i logiĉke zaštite IKT sistema.

- 512 -
4. MEĐUZAVISNOST SA DRUGIM SERVISIMA ZAŠTITE

Mere fiziĉke zaštite i zaštite okruţenja IKT sistema oslanjaju i

podrţavaju propisno funkcionisanje većeg broja servisa zaštite i to, [8]:

- logička kontrola pristupa,

- planiranje vanrednih dogaĎaja i kontinuiteta poslovanja,
- identifikaciju i autentifikaciju,

Ove mere su tesno povezane sa aktivnostima lokalne policije, stanica za

PPZ, stanicama hitne pomoći i medicinskim ustanovama i treba ih
konsultovati u fazi planiranja.

- 513 -
5. REZIME

Fiziĉka zaštita i zaštita okruţenja IKT sistema treba da se

zasnivaju na standardima i principima dobre prakse fiziĉke zaštite
znaĉajnih objekata, koji primenjuju standardne metode i kljuĉne principe
fiziĉke zaštite kao što su: zaštita po dubini, planiranje lokacije,
akomodacija, redovan nadzor i re-evaluacija zaštite, zaštita zaposlenih i
klijenata, upravljanje vanrednim dogaĊajima, fiziĉka zaštita
klasifikovanih informacija i objekta, fiziĉka zaštita raĉunarske opreme
konzistentno zaštiti informacija na papiru i zaštita medija za masivno
skladištenje.

U većini zemalja u svetu definisani su standardi za raĉunarsku sobu i

radne stanice, koji sadrţi ĉetiri nivoa (4. - najviši, 1.- najniţi). Fiziĉka
zaštita obuhvata zaštitu od humanih pretnji (provala, nereda, intercepcije
prenosnih signala) i sporednih aktivnosti (prosipanje toksiĉnih
hemikalija, eksplozije, vatra i elektromagnetske interferencije).

Zaštitu okruţenja IKT sistema, obezbeĊuju tehniĉki i ljudski servisi kao

što su elektriĉno napajanje, grejanje i hlaĊenje i telekomunikacije.
Nestandardan rad ovih sistema moţe prekinuti rad IKT sistema,
uzrokovati prekid davanje servisa, fiziĉka oštećenja hardvera, ili
uskladištenih podataka. Mere fiziĉke zaštite i zaštite okruţenja IKT
sistema obuhvataju osam glavnih oblasti: barijere za fiziĉki pristup,
protiv poţarna zaštita (PPZ), sistemi za grejanje, hlaĊenje i ventilaciju,
kolaps fiziĉke strukture, vodovodne instalacije, prisluškivanje podataka,
uticaj elektromagnetnih (EM) smetnji i mobilni ili prenosni IKT sistemi.

Specifiĉna fiziĉka zaštita EM i optiĉkih medija obuhvata procese

saniranja. - proces brisanja što je moguće više podataka i informacija sa
medija/opreme i deklasifikacije- uklanjanja ili redukcije nivoa
klasifikacije medija/opreme. Saniranje ne menja automatski klasifikaciju
medija/opreme, niti ukljuĉuje uništavanje medija/opreme. Proces
saniranja medija obuhvata ĉetiri nivoa (0.nivo-nema saniranja, 4. nivo-
uništavanje). Deklasifikacija se vrši na bazi procene rizika o
nepropisnom otkrivanju preostalih podataka u medijima/opremi i
eventualne prodaje, destinacije odlaganja, mogućnost popravke i
ugovornih obaveza.

- 514 -
Savremeno rešenje sistema fiziĉke zaštite ĉini integrisana fizička
infrastruktura okruţenja IKT sistema, koja obuhvata sledeće
komponente: sistem neprekidnog napajanja sa distribucijom, sistem
klimatizacije sa distribucijom hladnog vazduha, sistem senzora za nadzor
okruženja IS, jedinstvenu platformu za upravljanje i monitoring.

Tehnološka integracija sistema zaštite u mnogim oblastima fiziĉke i

logiĉke zaštite, dovodi do konvergencije logiĉke i fiziĉke zaštite u
integrisani sistem za upravljanje zaštitom, kojeg najbolje reprezentuje
tehnologija smart kartica.

- 515 -
6. KLJUĈNI TERMINI

Deklasifikacija medija: uklanjanje ili redukcija nivoa klasifikacije

medija ili opreme.
Demagnetizacija medija: smanjuje gustinu magnetskog fluksa
primenom reverznog magnetnog polja i obezbeĊuje neĉitljivost
prethodno snimljenih podataka i informacija.
Fiziĉka zaštita IKT sistema i okruţenja: zasniva se na standardima i
principima dobre prakse zaštite znaĉajnih objekata; primenjuje
standardnu metodologiju fiziĉke zaštite; obuhvata mere fiziĉko-tehniĉke
zaštite IKT sistema, zgrada i infrastrukture okruţenja.
Fiziĉki objekti: zgrade, druge graĊevinske strukture ili vozila u kojima
su smešteni IKT sistemi i/ili komponente raĉunarske mreţe.
Geografska operativna lokacija: odreĊuje karakteristike prirodnih
pretnji, koje ukljuĉuju zemljotrese i poplave, humane pretnje, kao što su
provale, neredi, intercepcija prenosnih signala i sekundarne štete od
toksiĉnih hemikalija, eksplozije, vatre i EM interferencije.
Intercepcija podataka: presretanje informacija na prenosnom putu i
prisluškivanje bez znanja legalnih korisnika: direktna opservacija,
intercepcija podataka u prenosu i TEMPEST izviĊanje elektronskih
signala putem kompromitujućeg EM zraĉenja (KEMZa).
Konvergencija fiziĉke i logiĉke kontrole pristupa: obezbeĊuju
tehnologije PKI, smart kartica i integracija digitalnih video,
protivprovalnih i PPZ senzora sa IKT sistemom.
Saniranje medija: proces brisanja što je moguće više podataka i
informacija sa medija ili kompjuterske opreme.
TEMPEST: (Transient Elektro-Magnetic Pulse Surveillance
Technology) Tehnologija za EM intercepciju KEMZ signala ili
(Transient Elektro Magnetic Pulse Emanating Standard) standard za
zaštitu od KEMZ-a, koji definiše oklapanje ureĊaja, ili celokupne opreme
u kompjuterskoj sobi i druge naĉine smanjenja širenja KEMZ signala.
Višekratno presnimavanje magnetskih medija: metod efikasnog
brisanja podataka uzastopnim binarnim „1―, i „0― i ponavljanjem ciklusa
više puta, zavisno od zahteva za deklasifikaciju ili od procenjenog rizika.
Zaštita okruţenja IKT sistema: obezbeĊuju tehniĉki objekti i tehniĉki i
ljudski servisi koji pomaţu i podrţavaju rad IKT sistema (napajanje,
grejanje, hlaĊenje i telekomunikacije).

- 516 -
7. LITERATURA

1. Australian Communications-Electronic Security Instruction 33,

Security Handbook, http://www.acsi.com, 2002. 1
2. David J. McKerrow, Canadian Handbook on Information
Technology Security, www.canadacss.com, 1999. 2
3. http://www.fas.org/irp/eprint/tempest.htm, 2006
4. http://www.phrack.org/show.php, 2006.
5. Markus G. K., Compromising emanations: eavesdropping risks of
computer displays, December 2003.
6. Mehdizadeh Yahya, Convergence of Logical and Physical
Security, SANS Institute, http://www.sans.org, 2004. 3
7. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
8. NIST SP 800-12, An Introduction to Computer Security: The
NIST Handbook, http://www.nist.gov/publications, verzija 2004.
4
9. Tanasijević P., Physical Infrastructure – Base for IT Centre
Security, Tehnicom Computers, THNK Group, IDC konferencija,
Beograd 2006. 5

- 517 -
5. UPRAVLJANJE OBUKOM I EDUKACIJOM O ZAŠTITI

0. UVOD

Po završetku ovog poglavlja razumećete:

- značaj razvoja svesti o potrebi i obuke o zaštiti

- strukturu programa za razvoj svesti o potrebi zaštite
- strukturu programa obuke o zaštiti
- značaj kontinuiteta procesa obrazovanja o zaštiti
- upravljanje procesom razvoja svesti i obuke o zaštiti

»Čujem i zaboravim, vidim i zapamtim, uradim i shvatim«

Kineska poslovica.

Korisnici-ljudi smatraju se najslabijom komponentom sistema IKT

zaštite, koja se moţe ojaĉati sa razvojem svesti o potrebi zaštite, obukom
i razvojem veština i izgradnjom potrebnih znanja za razvoj,
projektovanje, implementaciju i operativno odrţavanje sistema zaštite.
Realizaciju ove komponente zaštite obezbeĊuje program od tri gradivna
bloka, za: razvoj i podizanje svesti o potrebi zaštite, obuku za sticanje
veština i edukaciju u oblasti zaštite.

Samo korisnici svesni svoje odgovornosti u zaštiti i obuĉeni za korektnu

praksu, mogu menjati svoje ponašanje i povećati individualno prihvaćenu
kontrolisanu odgovornost (accountability), koja je najznaĉajnija za
poboljšanje sistema zaštite. Promena stava korisnika prvi je korak u
promeni ponašanja. Tek sa poznavanjem potrebe zaštite, neophodnih
mera zaštite i kako ih koristiti, korisnici mogu istinski prihvatiti
odgovornosti za svoje akcije i sprovoditi naloge politike zaštite.
Nacionalni Zakoni o zaštiti podataka i informacija u IKT sistemima
moraju obavezati menadţersku strukturu, korisnike i operatere sistema na
obaveznu edukaciju i obuku, adekvatnu odgovornostima i ulogama u
sistemu zaštite. Programi za razvoj svesti o potrebi zaštite, obuku i
obrazovanje u zaštiti višestruko su korisni za organizaciju u celini i
zahtevaju posebne metode i tehnike za implementaciju. Presudni su za
uspeh programa zaštite u celini, jer ako zaposleni nisu propisno
informisani o politici i procedurama zaštite, ne moţe se oĉekivati da rade
efektivno na zaštiti informacija i objekata IKT sistema.

- 518 -
Za upravljanje programom zaštite treba definisati kljuĉne faze ţivotnog
ciklusa programa: projektovanje, razvoj materijala, realizaciju
(implementaciju) i analizu i evaluaciju sa indikatorima kvaliteta
realizacije programa.

- 519 -
1. RAZVOJ SVESTI O POTREBI ZAŠTITE, OBUKA I
OBRAZOVANJE U ZAŠTITI

1.1. Definisanje programa za razvoj svesti o potrebi i obuku o zaštiti

Program za razvoj svesti o potrebi zaštite i obuku o zaštiti IKT sistema

razvija se kroz 4 faze ţivotnog ciklusa programa [8]:

1. Projektovanje programa: procena potreba, razvoj strategije

programa obuke, identifikacija zadataka za implementaciju programa.
2. Razvoj materijala programa: prikupljanje materijala iz svih
raspoloţivih izvora, definisanje obima i sadrţaja i izbor materijala.
3. Implementacija programa: efektivna komunikacija i prezentacija
programa na radnom mestu, preko web-a, uĉenje na daljinu i.t.d.
4. Analiza i evaluacija realizacije programa: izrada uputstva za
odrţavanje programa aţurnim i za monitorisanje efektivnosti, kroz
analizu povratnih informacija i evaluaciju rezultata obuke.

Kvalitetan program za razvoj svesti o potrebi zaštite i obuku o zaštiti IKT

sistema ĉine tri kljuĉna faktora, [4]:

1. razvoj politike i plana zaštite na bazi poslovnih potreba i poznatih

faktora rizika,
2. upoznavanje korisnika sa odgovornostima, dokumentovanim u
politici i procedurama zaštite i
3. uspostavljanje procesa za monitorisanje i evaluaciju programa zaštite.

Dobar model za obuku nudi standard COBIT. Ključni indikatori

sprovoĎenja obuke - KPI (Key Performance Indicators) mogu biti
brojni: procenat polaznika obuke, starosna dob polaznika i biografije
(Curiculum Vitae), vremenski period izmeĎu identifikacije potrebe za
obukom i same obuke, broj vrsta interne i eksterne obuke, procenat
obučenih korisnika o etičkim principima i praksi zaštite i broj
bezbednosnih incidenata po broju zaposlenih i sl.

- 520 -
Za lakšu evaluaciju programa obuke i merenje nivoa ostvarivanja ciljeva
programa treba definisati kritične faktore za uspeh programa–CSF
(Critical Success Factors), kao što su:
 Celovitost programa, koji istovremeno obuhvata individualne i
organizacijske potrebe;
 Finansijska podrška i potrebni resursi;
 Kritiĉnost obuke i svesti o potrebi zaštite za karijeru zaposlenih;
 Identifikovanje i dokumentovanje potrebe za obukom;
 Blagovremenost obezbeĊivanja potrebne obuke;
 Menadţerska podrška obuke zaposlenih na etiĉki i bezbedan naĉin;
 Menadţersko prihvatanje obuke kao investicije za smanjenje
ukupnih tehnoloških troškova;
 Zahtev politike organizacije da svi zaposleni imaju osnovnu obuku
koja obuhvata: etiĉke principe, praksu zaštite i prihvatljivo korišćenje
objekata IKT sistema;
 Obuka zaposlenih za praksu zaštite u funkciji spreĉavanja štete od
gubitka poverljivosti, raspoloţivosti, ili integriteta informacija i IKT
sistema.

Ljudski faktor je najbitniji u zaštiti IKT sistema i moţe naneti veću štetu
od svih drugih izvora pretnji zajedno. Jedna od namena ove komponente
zaštite je, upravo, da razvojem svesti o potrebi zaštite, individualne
odgovornosti i pretnje primene sankcija, smanje sluĉajne greške
zaposlenih korisnika IKT sistema, kao i prevare i neovlašćene aktivnosti
nezadovoljnih zaposlenih. Po pravilu, menadžerska struktura treba da
daje primer i odreĎuje pravila ponašanja organizacije prema
problematici zaštite. Ako zaposleni znaju da menadţeri ne obraćaju
paţnju na zaštitu, ni jedna program za razvoj svesti o potrebi zaštite i
obuku o zaštiti ne moţe biti efektivan. Zato je za program razvoja svesti
o potrebi zaštite i obuku o zaštiti lidersko ponašanje od presudnog
znaĉaja.

Program obuke je kritiĉan za upoznavanje zaposlenih i nametanje

obaveze sprovoĊenja politike zaštite u organizaciji. Ne moţe se
oĉekivati da zaposleni sprovode politiku i procedure zaštite, ili prihvataju
sankcije, ako sa njima nisu upoznati. Obuka ukazuje da je primenjen
standard profesionalne odgovornosti za zaštitu informacija, pa mnoge
organizacije koriste formu izjave o prihvatanju kojom se zaposleni
obavezuje da je proĉitao i razumeo bezbednosne zahteve.

- 521 -
1.2. Program za razvoj svesti o potrebi zaštite

Razvoj svesti o potrebi zaštite nije u kategoriji obuke. Namena ovog

procesa je usmeravanje paţnje menadţera i zaposlenih na problematiku
zaštite, prepoznavanje bezbednosnih problema u IKT sistemu i adekvatno
reagovanje. Što veći broj uĉesnika prima atraktivne pakete informacija,
bez toliko aktivnog uĉešća kao u procesu obuke, sa objašnjenjem šta za
misiju organizacije, klijente i zaposlene moţe znaĉiti, ako program
zaštite ne motiviše sve uĉesnike da zaštitu shvate krajnje ozbiljno. Svest
o potrebi zaštite stimuliše i motiviše menadţere i sve zaposlene da se
odgovorno brinu o zaštiti i cene znaĉaj prakse zaštite. Da bi se zaposleni
motivisali, program za razvoj svesti o potrebi zaštite treba da istiĉe u
kojoj meri i kako zaštita moţe doprineti produktivnosti, posledice loše
zaštite, bez izazivanja osećaja straha i odbojnosti zbog nepoznavanja,
kako obiĉno većina korisnika doţivljava zaštitu, [4].

Program podizanja svesti o potrebi zaštite moţe imati razliĉite forme za

razliĉite grupe uĉesnika. Primer izbora tema za program podizanja svesti
menadţera o potrebi zaštite dat je u PRILOGU III 5A, [4] Tipiĉni izvori
materijala za program podizanja svesti o potrebi zaštite su brojni:
obrazovne institucije, baze znanja na Internetu, profesionalne
organizacije i proizvoĎači proizvoda zaštite, časopisi o zaštiti,
konferencije, seminari i kursevi o zaštiti i dr.

Brojne su i raznovrsne tehnike i metode za implementaciju programa za

podizanja svesti o potrebi zaštite, ukljuĉujući video trake, multimedijalne
CD prezentacije, štampu, postere, biltene, prospekte, demonstracije,
kratkoroĉne podsetnike u log datotekama, razgovore i predavanja.
Program se obiĉno ugraĊuje u osnovni program obuke o zaštiti i moţe
koristiti bilo koji metod koji moţe promeniti stav zaposlenih prema
zaštiti. Efektivan program za razvoj svesti o potrebi zaštite obavezno
treba da obezbeĊuje korisniĉku prihvatljivost.

- 522 -
1.3. Program obuke o zaštiti

Osnovna razlika izmeĊu obuke i razvoja svesti o potrebi zaštite je

što se obukom osposobljavaju korisnici za izvršavanje specifiĉnih
funkcija zaštite, dok se procesom stvaranja svesti o potrebi zaštite
usmerava pažnja pojedinaca na odreĊena pitanja ili grupu pitanja iz
oblasti zaštite. Primer obuke je kurs bezbednosti i zaštite za
administratore sistema, koji mora obuhvatiti upravljaĉke, operativne i
tehniĉke kontrole zaštite koje treba implementirati u sistem. Lica koja
završe kurseve obuke iz oblasti zaštite treba da dobiju odgovarajuće
sertifikate. Cilj obuke u zaštiti je da se osposobe korisnici sa veštinama
koje im omogućavaju da bezbednije izvršavaju svoje aktivnosti u oblasti
zaštite, ukljuĉujući šta i kako treba ili mogu to da urade. Obuka moţe
obuhvatiti više nivoa, od osnovne prakse zaštite, preko srednjeg kursa
obuke do naprednog kursa, ili specijalizovanih veština i moţe biti
specifiĉna za jednu platformu ili dovoljno generiĉka da obuhvati sve
sisteme. Obuka je mnogo efektivnija kada je usmerena na specifiĉnu
grupu korisnika, jer omogućava savladavanje veština potrebnih za
redovne poslove zaposlenih. Polaznici kursa obuke mogu biti: opšti
korisnici i specijalisti koji zahtevaju naprednu obuku i posebne veštine,
[4].

Opšti korisnici treba da razumeju osnovne elemente dobre praksu zaštite,

kao što su:

 fiziĉka zaštita prostora i opreme (npr. zakljuĉavanje vrata, ĉuvanje

disketa i sl),
 zaštita pasvorda i drugih autentifikacionih podataka (nikada ne
otkrivati liĉni identifikator),
 izveštavanje o povredama sistema zaštite ili incidentima,
 politika zaštite organizacije, uloge i odgovornosti razliĉitih
organizacionih jedinica i
 druga pitanja koja se direktno odnose poboljšavanje osnovne prakse
zaštite korisnika.

- 523 -
Specijalizovana ili napredna obuka razliĉitih grupa korisnika detaljnija
je od osnovne prakse zaštite. Pojedinci/grupe za specijalizovanu ili
naprednu obuku mogu se identifikovati prema:

 kategoriji posla (npr. izvršni i funkcionalni menadţeri ili tehnološko

osoblje),
 radnim funkcijama (npr. projektant, operater, ili korisnik sistema), ili
 specifiĉnim tehnologijama i proizvodima koje koriste (npr. obuka za
rad sa novim IS).

Izvršni i funkcionalni menadţeri zahtevaju, pre specijalizovanu nego

naprednu obuku, jer po pravilu ne moraju razumeti tehniĉke detalje o
zaštiti, ali moraju znati da organizuju, usmeravaju i evaluiraju mere
zaštite i da shvate potrebu prihvatanja preostalog rizika.

Profesionalna obuka je specifiĉan vid obuke namenjen da svi korisnici,

od poĉetnika do profesionalaca u zaštiti, poseduju zahtevani nivo znanja i
sposobnosti, neophodnih za njihove profesionalne odgovornosti u zaštiti.
Za ovu obuku izdaju se odgovarajući sertifikati.
Tehnike i programi obuke o zaštiti normalno ukljuĉuju ĉasove teoretske i
praktiĉne obuke, na bazi multimedijalne prezentacije, predavanja, studija
sluĉajeva ili kombinacija ovih metoda.

- 524 -
1.4. Obrazovanje u zaštiti

Obrazovanje se definiše kao proces koji integriše sve veštine i

znanja u oblasti zaštite razliĉitih specijalnosti u jedinstvenu bazu
znanja, obuhvata koncepte, pitanja i principe multidisciplinarnih
nauka i osposobljava specijaliste i profesionalce zaštite za proaktivne
akcije u zaštiti. To je mnogo detaljnija obuka namenjena
profesionalcima u zaštiti, [4]. Primer: specijalistiĉke ili magistarske
studije sa odgovarajućim diplomama, kao deo razvoja profesionalne
karijere pojedinaca, koji se posvete zaštiti informacija.Tehnike i
program obrazovanja o zaštiti, izvan su obima i granica programa za
razvoj svesti o potrebi zaštite i obuci o zaštiti u većini organizacija. U
tabeli T.1.1. prikazani su uporedni parametri sve tri forme ove
komponente zaštite.

PARAMETRI SVEST O POTREBI OBUKA OBRAZOVANJE

Atribut: »Šta« »Kako« »Zašto«

Nivo: Informacija Poznavanje Detaljno znanje
Cilj: Prihvatanje potrebe Sticanje veština Razumevanje procesa
Praktiĉna nastava:
Teoretska nastava:
Multimedijska prezentacija: predavanja, studije
Metod: seminarski rad,diskusije,
video, štampa, posteri i.t.d. sluĉajeva, praktiĉne
samostalni rad
veţbe
Verifikacija Taĉno/pogrešno; Višestruki izbor Rešavanje problema Izrada eseja (rada)
znanja: (uĉenje identifikacijom) (primenjeno znanje) (interpretacija znanja)

Vreme uticaja: Kratkoroĉno Srednjeroĉno Dugoroĉno

T. 1.1. Komparacija parametara svesti o potrebi, obuke i

obrazovanja u oblasti zaštite

- 525 -
1.5. Kontinuitet procesa obrazovanja o zaštiti

Učenje i sticanje znanja o zaštiti je kontinualan proces, koji

poĉinje sa razvojem svesti o potrebi, izgraĊuje se kroz obuku i
kompletira u fazi obrazovanja. Model kontinuiteta procesa uĉenja i
osposobljavanja u zaštiti prikazan je na Sl. 1.1, [2], [4].
Obrazovanje

Specijalisti i profesionalci iz oblasti zaštite

A
Obrazovanje i iskustvo M
B

Uloge i odgovornosti u IKT sistemu A

Upravljanje Nabavka
Projektovanje Implement. Pregled i
Korišćenje Drugo M
i razvoj i rad evaluacija
Obuka

B B

Svi zaposleni uključeni u rad sa IKT sistemom

Osnovna bezbednosna pismenost
Svest o potrebi

A - napredni
Svi zaposleni
M - srednji
Svest o potrebi zaštite
B - početni

Sl. 1.1. Model kontinuiteta procesa uĉenja i osposobljavanja u zaštiti

Model se zasniva na premisi da je učenje kontinualan proces, koji

poĉinje sa razvojem svesti o potrebi zaštite, izgraĊuje kroz obuku, a
potpuno razvija kroz obrazovanje i obezbeĊuje kontekst za razumevanje i
korišćenje uputstva sa metodologijom za razvoj programa obuke. Potrebe
za uĉenje u oblasti zaštite model definiše na bazi uloga i odgovornosti
zaposlenih i pomaţe da se identifikuju znanja, sposobnosti i veštine koje
zaposleni treba da poseduje za specifiĉne zahteve na radnom mestu. Idući
prema vrhu modela obuka postaje obuhvatnija i detaljnija. Svi zaposleni
treba da steknu svest o potrebi zaštite. Obuka (»Osnovna bezbednosna
pismenost« i »Uloge i odgovornosti u IKT sistemu«), diferencira se na
poĉetni (B), srednji (M) i napredni (A) nivo zahteva za znanjima i
veštinama. Blok modela »Edukacija i iskustvo« primenjuje se primarno
na pojedince, koji bezbednost i zaštitu IKT sistema izaberu za svoju
profesiju.

- 526 -
2. UPRAVLJANJE PROGRAMOM OBUKE O ZAŠTITI

Za upravljanje bezbednosnim funkcijama programa obuke koriste se

tri modela, [8] :

 centralizovanog upravljanja, politikom, strategijom razvoja i

implementacijom;
 delimično decentralizovanog, centralizovana politika i strategija,
distribuirana implementacija i
 decentralizovanog upravljanja, centralizovana politika, distribuirana
strategija i implementacija..

Koji model će biti primenjen u velikoj meri zavisi od: veliĉine i

geografske disperzije IKT sistema i organizacije, definisanih uloga i
odgovornosti u organizaciji i finansijskih sredstava namenjenih za
program.
l
Centralizovano upravljanje primenjuje se u organizacijama koje su
relativno male, ili imaju centralizovano upravljanje većinom funkcija
IKT sistema, ili imaju sliĉne ciljeve poslovanja u svim organizacionim
jedinicama, ili imaju na upravnom nivou neophodne resurse, ekspertizu i
znanja o svim poslovima na nivou organizacionih jedinica. Odgovornost
i budţet za program obuke cele organizacije nalaze se kod centralnog
organa, koji koordinira razvoj, planiranje, realizaciju i evaluaciju
programa obuke (Sl. 2.1), [4]
Centralno telo

Upravljanje programom zaštite IKT sistema

- Politika - Sve finansije

- Strategija - Procena potreba
- Implementacija - Plan obuke

Organizaciona jedinica Organizaciona jedinica Organizaciona jedinica

Sl. 2.1. Centralizovano upravljanje programom obuke

- 527 -
Delimično decentralizovano upravljanje programom obuke o zaštiti
pogodan je za organizacije koje su relativno velike i imaju
decentralizovanu strukturu i upravljanje i jasne odgovornosti, ili imaju
geografski distribuirane organizacione jedinice, ili imaju organizacione
jedinice sa razliĉitim misijama i ciljevima poslovanja. Politiku i strategiju
razvoja programa definiše centralno telo za zaštitu, a implementaciju
rukovodioci organizacionih jedinica, koji raspolaţu sa budţetom,
materijalom, planom izvoĊenja programa i odgovorni su za realizaciju
(Sl. 2.2).

Centralno telo

Upravljanje programom zaštite IKT sistema

- Politika
- Procena potreba
- Strategija

Organizaciona jedinica Organizaciona jedinica Organizaciona jedinica

- budţet - budţet - budţet
- plan obuke - plan obuke - plan obuke
- implementacija - implementacija - implementacija

Sl. 2.2. Delimiĉno decentralizovano upravljanje programom

Decentralizovano upravljanje primenjuju organizacije koje su relativno

velike, ili imaju veoma decentralizovanu strukturu sa centralizovanim
opštim odgovornostima i distribuiranim specifiĉnim odgovornostima na
organizacione jedinice, ili imaju geografski distribuirane organizacione
jedinice, ili imaju poluautonomne radne jedinice sa razliĉitim misijama i
poslovnim ciljevima. Centralni organ zaštite kroz odgovarajuće
instrukcije i dobru strategiju nametanja distribuira politiku, zahteve i
oĉekivanja od programa obuke, ali prenosi odgovornost za realizaciju na
organizacione jedinice (Sl.2.3).

- 528 -
 Centralno telo

Upravljanje programom zaštite IKT sistema

- Politika - Procena potreba

Organizaciona jedinica Organizaciona jedinica Organizaciona jedinica

- procena potreba - procena potreba - procena potreba
- budţet - budţet - budţet
- plan obuke - plan obuke - plan obuke
- implementacija - implementacija - implementacija

Sl. 2.3. Potpuno decentralizovano upravljanje programom

- 529 -
3. PROCES RAZVOJA PROGRAMA OBUKE O ZAŠTITI

Projektni pristup razvoja programa za obuku o zaštiti, ukljuĉujući

razvoj svesti o potrebi zaštite, obuhvata izvršavanje procesa, procedura i
aktivnosti kroz sledeće kljuĉne faze i korake ţivotnog ciklusa programa:
pripreme, projektovanja, implementacije i evaluacije, koje obezbeĊuju
konzistentno upravljanje programom obuke [8]:
Faza 1: Priprema za razvoj programa
Korak 1: Procena potreba
Korak 2: Identifikacija obima i ciljeva programa.
Korak 3: Identifikacija nastavničkog i instruktorskog osoblja.
Korak 4: Identifikacija ciljne grupe za obuku.
Korak 5: Motivacija menadžmenta i zaposlenih.
Faza 2: Projektovanje programa
Korak 6: Izrada plana
Korak 7: Izbor materijala
Faza 3: Implementacija programa
Korak 8: Administracija programa.
Korak 9: Održavanje programa.
Faza 4: Evaluacija programa.
Korak 10: Upravljanje promenama (faza posle evaluacije)

- 530 -
3.1. Priprema za razvoj programa

Procena potreba identifikuje odgovarajući model i priprema

razvoj programa obuke konzistentno izabranom modelu. U PRILOGU
III 5B prikazane su tehnike skupljanja informacija za razvoj programa
obuke (T. 3.1) i kljuĉna pitanja za upitnik (T. 3.2). Primer detaljnog
upitnika i ostalih radnih dokumenata za procenu potreba i obuku sistem
administratora prikazan je u PRILOG III 5C.

Identifikacija obima i ciljeva programa prvi je korak u razvoju

programa obuke o zaštiti za sve vrste korisnika i uĉesnika koji
interaktivno rade u IKT sistemu: za celu organizaciju, deo ili
organizacionu jedinicu. Program za celu organizaciju ĉesto zahteva
specifiĉne dopune pošto korisnici imaju potrebu za obukom koja se
odnosi direktno na korišćenje odreĊenog sistema,. U programu treba
specifiĉno naglasiti da li se obuka odnosi samo na zaposlene, ili i na
druge korisnike IKT sistema organizacije. Generalno, krajnji cilj
programa je da odrţi odgovarajući nivo zaštite objekata IKT, povećanjem
svesti zaposlenih o njihovim odgovornostima u zaštiti i kako da ih
ispune. Dugoroĉni cilj programa treba da obuhvata sve kratkoroĉne
ciljeve obuke.

Identifikacija nastavničkog i instruktorskog osoblja sa dovoljno znanja

iz oblasti zaštite IKT sistema, koji poznaju principe i tehnologije zaštite i
poseduju komunikativne sposobnosti za efektivan prenos znanja i
iskustava, moţe obuhvatiti zaposlene specijaliste zaštite, kompetentne
specijaliste izvan organizacije ili specijalizovane organizacije.

Identifikacija ciljne grupe za obuku potrebna je jer svi

korisnici/zaposleni nemaju jednake potrebe za obukom. Program obuke
treba prilagoditi potrebama odreĊene grupe korisnika i da dobiju samo
informacije potrebne za bezbedno obavljanje poslova. Segmentacija
grupa polaznika za obuku o zaštiti, moţe se izvršiti prema:

- nivou znanja i svesti o potrebi zaštite (procena kvaliteta

sprovoĊenja procedura zaštite),
- radnim zadacima ili funkcijama (kreatori, obraĊivaĉi ili korisnici
podataka),
- specifičnim kategorijama poslova (opšti poslovi, tehnološka
struktura, zaštita i dr.),

- 531 -
 - nivou informatičkog znanja, (eksperti za zaštitu, tehniĉka
podrška, upravna struktura),
- korišćenom tipu tehnologije zaštite (korisnici glavne aplikacije,
novi proizvodi i dr.)

Motivacija menadžmenta i zaposlenih obezbeĊuje podršku

menadţmenta i zaposlenih i normalno se odnosi na razvoj svesti o
potrebi zaštite, ulogu obuke o zaštiti i potencijalne štete koje zaštita moţe
smanjiti. Motivacija menadţmenta je neophodno zbog podrške i
potrebnih resursa za razvoj i implementaciju programa obuke, ali nije
dovoljna za uspeh programa obuke. Zaposleni moraju biti ubeĊeni u
korisnost zaštite, razumeti vrednosti objekata sa kojima rade i kako se
zaštita odnosi na njihove poslove, što se bez odgovarajuće obuke ne
moţe postići.

- 532 -
3.2. Projektovanje programa zaštite

Razvoj plana obuke ubrzava pripremu i realizaciju programa

obuke. Metodologija opisana u [2], obezbeĊuje izradu plana i dobru
pripremu materijala za brojne tipove obuke u oblasti zaštite i opisuje
naĉine korišćenja metodologije. Ova metodologija obezbeĊuje koristan
pomoćni alat za razvoj kursa za obuku, a obuhvata potrebe obuke u
zaštiti u realnom distribuiranom kompjuterskom okruţenju. Zasniva se na
ulogama i odgovornostima zaposlenih/korisnika. Identifikuje 26 uloga
koje imaju odreĊeni stepen odgovornosti u IKT sistemu za oblast zaštite,
ali je fleksibilna u pogledu definisanja broja uloga u konkretnoj
organizacija. Omogućava organizaciju kurseva obuke za početni, srednji
i napredni nivo. Za svaki nivo obuke definiše ciljeve, uzorak tema i
materijala, kao i uputstvo za organizatore programa obuke. U mapiranju
uloga, tema i materijala, organizacije mogu koristiti uzorke i fleksibilno
dodavati nove uloge, teme, materijale ili izostavljati zastarele ili
prevaziĊene, [4].

Metodologija ukljuĉuje brojne resurse za pripremu kursa za obuku o

zaštiti, kao što su: model kontinuiteta učenja u zaštiti, matrica 26 uloga i
odgovornosti u zaštiti, 46 ćelija matrice za obuku, 12 tema i koncepata u
bazi znanja, 3 osnovne kategorije sadržaja obuke i 6 funkcionalnih
specijalnosti. Korisno je izraditi Uputstvo za obuku o zaštiti na bazi ove
metodologije.

Pripremu materijala za obuku i projektovanje adekvatnog sadrţaja i

forme kursa obuke usmeravaju i pomaţu prilozi metodologije [2]. Za
definisanje programa, izbor i pripremu materijala treba koristiti pomoć
specijalista za zaštitu, pošto ĉesto organizatori kurseva obuke nisu iz
oblasti zaštite. Neka organizacija izabere obuku na bazi poloţaja i uloga
zaposlenih u organizaciji. Metodologija sadrţi 26 matrica, po jedna za
svaku od 26 identifikovanih uloga. U Tabeli 3.3. prikazan je uzorak
matrice za kurs obuke sistem administratora.

- 533 -
 Oblast obuke Funkcionalne specijalnosti (kategorije uloga)
A B C D E F G

Implemen-
Dizajn
1. Zakon i Upravlja- tacija i Pregled i Korišć- Ostal
Nabavka i
regulativa nje operativna evaluacija enje o
razvoj
primena
2. Program zaštite 1.D√
2.1. Planiranje
2.2.Upravljanje
3. Ţivotni ciklus
2.2.D√
sistema zaštite
3.1. Inicijacija
3.2. Razvoj 3.1.D√
3.3. Testiranje i
3.2.D√
evaluacija
3.4.Implementacija 3.3.D√
3.5. Operativna
3.4.C√ 3.4.D√
primena
3.6. Odlaganje
3.5.A√ 3.5.C√ 3.5.D√
sistema
4. Ostalo 3.6.D√

T. 3.3. Uzorak matrice bezbednosne obuke sistem administratora

U svakoj matrici nalazi se odreĊeni broj ćelija koje se koristi za pripremu
materijala za kurs odreĊenog tipa obuke. Ima ukupno 46 ćelija, ali se
samo specifiĉne ćelije koriste za svaki kurs. Neke matrice kurseva imaju
svega dve ćelije, a matrica kursa za obuku menadţera zaštite koristi svih
46 ćelija. Većina matrica za kurseve obuke u zaštiti koriste 7 do 10 ćelija.
Svaka ćelija matrice obuke u zaštiti IKT sistema detaljno se prikazuje u
formi tabela. Detaljniji opis organizacije matrice i format ćelije matrice
obuke o zaštiti i druga radna dokumenta detaljnije su opisana U
PRILOGU III 5D.

- 534 -
3.3. Implementacija programa

Na slici 3.2. prikazana su ĉetiri kljuĉna koraka u procesu

implementacije programa za razvoj svesti o potrebi i obuku o zaštiti:

Implementacija

Razvoj i priprema materijala za stvaranja

svesti o potrebi zaštite i obuku u zaštiti

Dizajn programa za stvaranja svesti o potrebi

zaštite i obuku u zaštiti
- procena potreba
- razvoj strategije
- razvoj plana

Sl. 3.2. Kljuĉni koraci u implementaciji programa

Znaĉajne aktivnosti u implementaciji programa obuke su:

 izbor tema za program podizanja svesti o potrebi zaštite i program

obuke,
 pronalaţenje izvora i materijala za obuku,
 implementacija programa korišćenjem raznovrsnih metoda,
 evaluacija efektivnosti programa i
 aţuriranje i poboljšanje programa prema organizacionim i
tehnološkim promenama.

Administracija programa obuke o zaštiti obuhvata nekoliko vaţnih

komponenti:
Transparentnost: kljuĉna za uspešnu realizaciju, ne treba obećavati ono
što se ne moţe ispuniti;
Metodi obuke: konzistentni sa materijom koja se izlaţe, prilagoĊeni
nivou grupe;
Teme: izabrane prema potrebama korisnika;
Materijal: što kvalitetniji (traţeniji, ali i skuplji, dobijen/iznajmljen i
modifikovan);

- 535 -
Prezentacija: paţljivo se bira (godišnje, po potrebi, 20 min.-opšta tema, 1
sat-aţuriranje znanja, 7 dana-obuka izvan organizacije; naĉin-formalna,
neformalna diskusija sa humorom i sl.)

Održavanje programa aţurno prati i ukljuĉuje sve promene tehnologija

IS i zaštite, zakonske regulative ili politika zaštite organizacije. Program
obuke mora biti aktuelan i da nudi tekuće informacije korisne za
bezbedan rad zaposlenih.

- 536 -
3.4. Evaluacija programa

Upravljanje promenama u programu obuke o zaštiti koristi rezultate

evaluacije kvaliteta realizacije programa za aţuriranje i korekciju
programa za novi ciklus obuke. Ĉesto je teško meriti efektivnost
programa obuke, ali se evaluacija mora se izvršiti da se utvrdi u kojoj
meri polaznici obuke usvajaju znanja i veštine i sprovode procedure
zaštite i kakav je stav prema zaštiti. Neki metodi evaluacije koji se mogu
koristiti i kombinovano, su:

- klasična provera stečenih znanja,

- praćenje sprovoĎenja preporučene procedure zaštite,
- korišćenje zapažanja polaznika kursa o efektima obuke i
- monitorisanje broja i tipova kompjuterskih incidenata pre i posle
obuke.

Na slici 3.3. prikazani su razliĉiti metodi evaluacije i tehnika za

aţuriranje programa obuke.

Proces razvoja svesti o potrebi i obuku u zaštiti treba integrisati u opštu

poslovnu strategiju. Zreo proces programa treba da definiše metriku
(kvalitativnu, kvantitativnu, binarnu). Primer metriĉkog sistema za
evaluaciju programa obuke u zaštiti prikazan je u PRILOG III 5E, [8].

Benčmarking

Anketa Tehnološki pomak

Revidiran plan za
Evaluacione forme stvaranja svesti o Diskusiona grupa
potrebi zaštite i
obuku u zaštiti

Nezavisna
Intervijui
opservacija/ analiza

Izveštaji o statusu

Sl. 3.3. Evaluacija i tehnike povratne sprege za kontrolu programa

- 537 -
4. MEĐUZAVISNOST SA DRUGIM KONTROLAMA ZAŠTITE

Ova komponenta zaštite odnosi se na sve ostale, a posebno na.

- Politike zaštite: kroz obuku informišu se zaposleni o sadrţaju i

razlozima;
- Upravljanje programom zaštite: oba usklaĊen sa Zakonom o
zaštiti informacija u IS i
- Personalnu zaštitu: ĉesto se ukljuĉuje u komponentu personalne
zaštite.

- 538 -
5. REZIME

Program za podizanje svesti o potrebi zaštite i obuku o zaštiti

razvija se kroz 4 identifikovane faze ţivotnog ciklusa programa:
projektovanje, razvoj materijala, implementaciju i analiza i evaluacija
programa.

Ključni indikatori sprovoĎenja obuke (KPI) mogu biti: procenat

polaznika obuke, starosna dob polaznika i biografije (CV), broj vrsta
obuke, broj incidenata po broju zaposlenih i sl. Kritični faktori za uspeh
programa (CSF), olakšavaju evaluaciju programa, a mogu biti: celovitost
programa, finansijska podrška i resursi, karijera zaposlenih,
identifikovana i dokumentovana potreba, podrška glavne upravne
strukture i dr..

Razvoj svesti o potrebi zaštite, nije u kategoriji obuke nego usmeravanje

pažnje na problematiku zaštite, prepoznavanje bezbednosnih problema u
IS i adekvatno reagovanje na njih. Obuka o zaštiti osposobljava
zaposlene veštinama, koje im omogućavaju bezbedniji rad. Moţe
obuhvatiti više nivoa, od osnovne prakse zaštite do naprednog kursa
obuke i specijalizovanih veština. Obrazovanje o zaštiti je proces koji
integriše sva znanja i veštine iz razliĉitih specijalnosti u jedinstvenu bazu
znanja o konceptima i principima zaštite iz multidisciplinarnih nauka i
osposobljava specijaliste i profesionalce zaštite za proaktivnu strategiju
zaštite. Učenje i sticanje znanja o zaštiti je kontinualan proces, koji
poĉinje sa stvaranjem svesti o potrebi, izgraĊuje se kroz obuku i potpuno
razvija u procesu obrazovanja.

Za upravljanje programom obuke koriste se tri modela: centralizovano

upravljanje, delimiĉno decentralizovano upravljanje, i decentralizovano
upravljanje.
Proces razvoja programa obuke o zaštiti, ukljuĉujući i razvoj svesti o
potrebi zaštite, izvršava se kroz 4 kljuĉne faze: pripremu (procena
potreba, identifikacija obima i ciljeva programa., identifikacija
nastavniĉkog osoblja, identifikacija ciljne grupe za obuku, motivacija
menadţera i zaposlenih, projektovanje (izrada plana, izbor materijala),
implementacija (administracija programa, odrţavanje programa) i
evaluacija programa (upravljanje promenama).

- 539 -
Metodologija za pripremu i razvoj materijala za obuku obezbeĊuje
pripremu materijala za brojne tipove obuke u oblasti zaštite i opisuje
naĉin korišćenja metodologije. Brojni resursi detaljno se opisuju u
adekvatnom »Uputstvu za obuku o zaštiti«. Metodologija je fleksibilna u
pogledu definisanja broja uloga u konkretnoj organizacija, a omogućava
organizaciju kurseva obuke za poĉetni, srednji i napredni nivo. Program
obuke mora da pratiti promene tehnologija IS i zaštite, okruţenja i
normativnog okvira i treba ga integrisati u opštu poslovnu strategiju.
Zreo proces programa obuke o zaštiti treba da definiše metriku
(kvalitativnu, kvantitativnu, binarnu) za ovu komponentu zaštite.

Komponenta obuke o zaštiti odnosi se na i proţima sa gotovo svim

preostalim komponentama zaštite, a posebno sa: politikom zaštite,
upravljanjem programom zaštite i personalnom zaštitom.

- 540 -
6. KLJUĈNI TERMINI

Kontinuitet uĉenja: kontinualan proces, koji poĉinje sa razvojem svesti

o potrebi, izgraĊuje se kroz obuku i kompletira u fazi obrazovanja.
Obrazovanje u zaštiti: proces koji integriše sve veštine i znanja u
oblasti zaštite razliĉitih specijalnosti u jedinstvenu bazu znanja, obuhvata
koncepte, pitanja i principe multidisciplinarnih nauka i osposobljava
specijaliste i profesionalce zaštite za proaktivne akcije u zaštiti.
Obuka o zaštiti: osposobljava korisnike sa veštinama koje im
omogućavaju da bezbednije izvršavaju svoje aktivnosti u oblasti zaštite,
ukljuĉujući šta i kako treba ili mogu nešto da urade.
Program obuke (Training program): struktuiran pristup razvoju i
postizanju kompetentnosti odreĊene kvalifikacione grupe za postizanje
zahteva postavljenih u Paketu obuke. Ukljuĉuje izbor modula, metoda i
lokacije obuke za ispunjavanje zahteva i potreba polaznika kursa obuke
za sticanjem znanja, veština i sposobnosti.
Razvoj svesti o potrebi zaštite: nije u kategoriji obuke, usmerava paţnju
menadţera i zaposlenih na problematiku zaštite, prepoznavanje
bezbednosnih problema u IS i adekvatno reagovanje.
Standard obuke (Standard): precizna izjava o zahtevanom nivou
sticanja znanja, veština i sposobnosti u procesu obuke, koji se smatra
kompetentnim za izvršavanje odreĊenog posla.
Strategija uĉenja (Learning strategy): komponenta paketa obuke koja
obezbeĊuje informaciju o tome kako program obuke mora biti
organizovan na radnom mestu ili obrazovnoj instituciji. Strategija uĉenja
komplementarno dopunjuje odobren paket obuke.
Veština (Skill): moţe biti percepcijska, motoriĉka, manuelna,
intelektualna ili sociološka. Priroda poslova obiĉno zahteva kombinaciju
ovih i obiĉno ukljuĉuje aplikaciju kognitivnih i psihosomotoriĉkih
funkcija, zajedno sa odgovarajućim znanjem

- 541 -
7. LITERATURA

1. Australasian Police Education Standards Council Inc.(APESC),

Training Package: User Guide for the Policing Profession,
www.apesc.org, 2001.
2. Dorothea E. de Zafra, Sadie I. Pitcher, Information Technology
Security Training Requirements: A Role- and Performance-Based
Model, NIST SP 800-16, http://www.nist.gov/publications,1998.
3. Mark Wilson and Joan Hash, Information Technology Security
Awareness,Training, Education, and Certification, NIST, ITL
Bulliten, http://www.nist.gov/publications, 2003.
4. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
5. NIST SP 800-12, An introduction to computer security: The NIST
Handbook, http://www.nist.gov/publications,2004.
6. Swanson Marianne, Guide for Developing Security Plans for Information
Technology Systems, NIST SP 800-26,
http://www.nist.gov/publications,1998.
7. Swanson Marianne, Security Self-Assessment Guide for Information
Technology Systems, NIST SP 800-18,
http://www.nist.gov/publications,1999.
8. Wilson Mark and Hash Joan, Building an Information Technology
Security Awareness and Training Program, NIST SP 800-50,
http://www.nist.gov/publications, 2003.

- 542 -
6. UPRAVLJANJE KONFIGURACIJOM

0. UVOD

Po završetku ovog poglavlja naučićete:

- razviti plan za upravljanje/ispitivanje promena konfiguracije

- principe i proces upravljanja promenama konfiguracije:
osnovnog sistema, IKT sitema, RM, servisa za AC, ...
- konfiguraciju minimuma servisa
- proces verifikacije bezbedne konfiguracije sistema

Efektivno upravljanje konfiguracijom treba da ukljuĉi dobro

osmišljen plan, izraĊen neposredno posle iniciranja projekta. Ovaj plan
treba da opiše, jednostavnim pozitivnim saopštenjima šta treba uraditi u
IKT i sistemu zaštite. Minimalan plan upravljanja konfiguracijom moţe
jednostavno definisati kako će upravljanje konfiguracijom biti
implementirano, što se odnosi na glavne principe procesa upravljanja
konfiguracijom: identifikaciju, upravljanje (kontrolu), evidentiranje
(registrovanje) i reviziju (audit). Plan upravljanja konfiguracijom treba
da sadrţi dovoljno detaljna saopštenja koja opisuju kako zadaci
upravljanja konfiguracijom treba da se izvrše, tako da ga svaki uĉesnik u
projektu moţe konsultovati za svaki specifiĉni zadatak.

Plan za upravljanje konfiguracijom treba da obezbeĊuje poznavanje

konfiguracije sistema i kontrolu promena kroz ceo ţivotni ciklus sistema.
Plan za upravljanja konfiguracijom razvija se ako Plan zaštite
organizacije nije adekvatan za upravljanje promenama sistema.

Plan za upravljanje konfiguracijom IS treba da bude konzistentan sa

standardom, da se evaluira periodiĉno (npr. godišnje) i aţurira po potrebi
da bi se verifikovali usklaĊenost plana i prakse zaštite i sposobnosti
odgovornih lica za sprovoĊenje plana.

Bezbednosni cilj upravljanja konfiguracijom proistiĉe iz ĉinjenice da

bezbednost raĉunarskog sistema, koji procesira i skladišti osetljive ili
klasifikovane informacije, zavisi od bezbednosti hardvera i softvera koji
treba da štite te informacije. To znaĉi da hardver i softver, takoĊe, treba
da budu zaštićeni od neovlašćenih izmena, koje mogu izazvati loše
funkcionisanje mehanizama zaštite ili njihovo potpuno zaobilaţenje. Zato

- 543 -
se promene konfiguracije IS i sistema zaštite moraju pratiti i kontrolisati
tokom ĉitavog ţivotnog ciklusa, da bi se obezbedilo odrţavanje
integriteta mehanizama zaštite. Samo na ovakav naĉin moţe se steći
poverenje da se hardversko-softverska implementacija politike zaštite
odrţava korektno i bez izmena.

Proces upravljanja konfiguracijom optimalno treba da se izvršava kroz

sledeće procedure, koje treba razviti, dokumentovati i implementirati u
skladu sa politikom zaštite organizacije: izrada plana za upravljanje
promenama konfiguracije, upravljanje promenama osnovne
konfiguracije računarskog sistema, upravljanje promenama u IKT
sistemu, upravljanje promenama servisa za kontrolu pristupa,
monitorisanje promena konfiguracije, konfigurisanje minimuma servisa,
kontrola (auditing) i verifikacija bezbedne konfiguracije, upravljanje
konfiguracijom računarske mreže, politika zaštite privatnosti i
ograničavanje tipova saobraćaja.

- 544 -
1. PROCES UPRAVLJANJA PROMENAMA KONFIGURACIJE

1.1. Pregled principa za upravljanje konfiguracijom

Upravljanje konfiguracijom je dobra inţenjerska praksa koja

obezbeĊuje garanciju da sistem u operativnoj praksi funkcioniše onako
kako treba.

Namena procesa upravljanja konfiguracijom je da obezbedi da se

neizbeţne promene u sistemu odvijaju na poznat i kontrolisan naĉin i da
ne utiĉu negativno na bilo koju funkciju sistema ili implementaciju
politika zaštite. Proces upravljanja konfiguracijom zasniva se na ĉetiri
osnovna principa, [13]:

– identifikacija,
– kontrola promena konfiguracije,
– evidencija (registrovanje) stanja konfiguracije i
– revizija (auditing) procesa upravljanja konfiguracijom.

a. Identifikacija svake promena u sistemu osnovni je princip procesa

upravljanja konfiguracijom. Procedura upravljanja konfiguracijom treba
da omogući da odgovorno lice blagovremeno identifikuje konfiguraciju
sistema u diskretnim taĉkama u cilju sistematske kontrole promena u
konfiguraciji u svim fazama ţivotnog ciklusa. Osnovna funkcija je
identifikacija komponenti sistema u fazi projektovanja i implementacije
sistema.

Upravljanje osnovne konfiguracije (eng. baseline management) jedna je

od tehnika identifikacije konfiguracije, što je osnova koncepta sistema
upravljaĉkih operativnih i tehniĉkih kontrola osnovne zaštite (eng.
baseline protection). Svaka promena svake komponente sistema u
odnosu na osnovnu konfiguraciju treba da bude odobrena,
dokumentovana i kontrolisana u svim fazama ţivotnog ciklusa.

b. Kontrola promena konfiguracije vrši se izvršavanjem procedura

revizije i odobravanja od strane ovlašćenih lica svake promene
dokumentacije, hardvera, softvera i firmware. Kontrola konfiguracije
ukljuĉuje sistematsku evaluaciju, koordinaciju, odobravanje ili
neodobravanje predloţenih promena projekta i konstrukcije objekata
konfiguracije, ĉija je konfiguracija formalno već odobrena. Kontrola

- 545 -
konfiguracije treba da poĉne u ranoj fazi projektovanja i razvoja sistema i
da se odrţava u ostalim fazama ţivotnog ciklusa. Efikasnu kontrolu
promena obezbeĊuje ispunjavanje sledećih kriterijuma, [13], [17]:

- evidentiranje korisniĉkog vremena i datuma poslednje promene

sadrţaja informacija,
- izvršavanje promena samo od strane ovlašćenih lica,
- propisna implementacija planiranih promena,

zaštićen, nepromenljiv, kontrolni trag za jasno evidentiranje promena.

c. Evidentiranje statusnih informacija konfiguracije podrazumeva

registrovanje podataka i izveštavanje o statusu konfiguracije posle svake
promene. Registrovanje podataka o statusu konfiguracije je odgovornost
sa obavezom izveštavanja o progresu razvoja na vrlo specifiĉan naĉin.
Ovaj se zadatak izvršava kroz procese evidentiranja podataka,
skladištenja podataka i izveštavanja o stanju konfiguracije sistema.
Glavni cilj je registrovanje i izveštavanje o svim informacijama od
znaĉaja za proces upravljanja konfiguracijom.

d. Revizije (kontrola, auditing) procesa upravljanja konfiguracijom

verifikuje korektnost funkcionisanja i usklaĊenost sa politikom zaštite i
bezbednosnim zahtevima za kompletnu izmenu u sistemu. Revizija
procesa upravljanja konfiguracijom obuhvata pregled kontrolnih lista za
proveru svih evidentiranih podataka, da bi se utvrdilo da su izvršene
samo ovlašćene promene. Svaka promena izvršena u sistemu zaštite treba
da se revidira i da se kontroliše njen efekat na ostatak sistema. Ovo
ukljuĉuje reviziju i ispitivanje (testiranje) svih programa da bi se
proverila korektnost izvršenih promena. Ispituje se proces evidentiranja
kontrolnih tragova, ĉime se proverava da li se promene ponašaju kako je
oĉekivano.

- 546 -
1.2. Zahtev za promene

Formulari za podnošenje zahteva za promene sistemskih

programa, koriste se da bi se dokumentovali zahtevi i odobrenja koja se
na njih odnose. Za nove verzije sistemskih programa ili modifikaciju
postojećih treba obezbediti propisno ovlašćenje za rad, sa dokumentom
zahteva za promenu u prilogu. Zahteve za promenu odobrava zvaniĉno
lice iz organizacije, a ukljuĉuju, izmeĊu ostalog, korisnike i osoblje za
tehniĉku podršku IS.

1.2.1. Zahtev za hitne promene

Zahtev za hitne promene u IS prima se i dokumentuje, a odobrava

ga zvaniĉni organ organizacije, pre ili posle same promene. Izvršene
hitne promene konfiguracije na odgovarajući naĉin se dokumentuju i
odobravaju, a evidentira se odgovarajući personal za analizu i realizaciju
zahteva.

- 547 -
2. RAZVOJ PROCEDURA ZA PROCES UPRAVLJANJA
KONFIGURACIJOM

Procedure u planu za upravljanje konfiguracijom treba da budu

razvijene i dokumentovane, što obezbeĊuje da se upravljanje
konfiguracijom izvršava na specificiran naĉin.

Proces upravljanja promenama konfiguracije optimalno obuhvata sledeće

procedure, koje treba razviti, dokumentovati i implementirati u skladu sa
politikom zaštite organizacije, [13], [17], [10]:

- izrada plana za upravljanje promenama konfiguracije,

- upravljanje promenama osnovne konfiguracije IKT sistema,
- upravljanje promenama u IKT sistemu,
- upravljanje promenama servisa za kontrolu pristupa,
- monitorisanje promena konfiguracije,
- konfigurisanje minimuma servisa,
- kontrola i verifikacija bezbedne konfiguracije,
- upravljanje konfiguracijom računarske mreže,
- politika zaštite privatnosti i
- ograničavanje tipova saobraćaja.

- 548 -
2.1. Izrada plana za upravljanje promenama konfiguracije

U skladu sa politikom organizacije treba razviti, dokumentovati i

efikasno implementirati detaljne procedure za upravljanje konfiguracijom
IS i sistema zaštite.

Proces upravljanja konfiguracijom mora biti konzistentan sa planom

arhitekture IKT sistema i sistema zaštite organizacije. Formalno
dokumentovane uloge, odgovornosti i procedure za upravljanje
konfiguracijom ukljuĉuju upravljanje bezbednosnim informacijama i
dokumentacijom zaštite IS. Dokumentuju se i ovlašćenje odgovornog lica
iz organizacije za promene u IKT sistemu, koje nisu moguće izvan
procesa upravljanja konfiguracijom. ObezbeĊuje se obuka i upoznavanje
sa procesom upravljanja konfiguracijom lica ukljuĉenih u upravljanje
konfiguracijom. Uputstvo i materijal za obuku treba da odgovaraju
korisnicima sa razliĉitim nivoima znanja i iskustva. Za evidenciju
kontrolnih informacija o promenama sistemskih i aplikativnih programa,
odrţavanje brojeva verzija programa, evidenciju i izveštavanje o
promenama hardvera i firmware i kontrolu aţuriranja konkurentnih
promena, koriste se odgovarajući alati.

2.1.1. Izrada plana za upravljanje promenama objekata IKT sistema

Plan za upravljanje konfiguracijom treba da sadrţi potpuno

dokumentovane procedure:

– praćenja svih promena korisnika, dokumentacije, hardvera,

softvera i firmware;
– uputstvo za kreiranje i odrţavanje funkcionalnih testova i
dokumentacije kroz ţivotni ciklus sistema;
– predlaganja, evaluacije, koordinacije i odobravanja promena u
svim neophodnim oblastima i
– izvršavanja hitnih promena sa definisanim koracima za
retroaktivnu implementaciju upravljanja konfiguracijom posle
kompletiranja hitnih promena.

Plan za upravljanje konfiguracijom je ţivi dokument i treba da ostane

fleksibilan u fazama projektovanja i razvoja.

- 549 -
Plan treba da obuhvati periodiĉnu reviziju promena programa od strane
odgovornih lica iz organizacije i kontrolu korektnosti sprovoĊenja prava
pristupa i promena korisniĉkih naloga i prava pristupa. Plan za
upravljanje konfiguracijom treba da se periodiĉno evaluira, npr. jedan put
godišnje. Treba da se planira: kontrola distribucije novih programa,
upotrebe licenciranog softvera i eventualne povreda ovih sporazuma;
provera ograniĉenog korišćenja personalno i javno dostupnih programa;
identifikovanje i dokumentovanje imena, marke, tipa, modela,
verzije/broja objavljivanja i fiziĉke lokacije svake komponente IKT
sistema - hardvera, programa i firmware.

2.1.2. Izrada plana za ispitivanje promena

Za ispitivanje (validaciju, testiranje) promena konfiguracije IKT

sistema na svim nivoima treba razviti interne standarde za izradu plana za
ispitivanja, koji definiše odgovornosti svih uĉesnika, tj. korisnika, sistem
analitiĉara, programera, kontrolora, ispitivaĉa sistema kvaliteta i
kontrolora biblioteka. Plan za ispitivanje promena konfiguracije mora biti
dokumentovan i odobren. Plan takoĊe, treba da obuhvati i odgovarajuće
razmatranje bezbednosnih pitanja. Ispitivanje ureĊaja, integracije ureĊaja
i sistema vrši se i odobrava u skladu sa planom za ispitivanje i uz
primenu dovoljnog opsega kriterijuma za ocenu validnosti i nevalidnosti
rezultata ispitivanja. Treba razviti sveobuhvatni skup procedura za proces
ispitivanja koje obuhvataju razliĉite aktivnosti i uslove, oĉekivane u toku
rada IKT sistema. Rezultati ispitivanja revidiraju se i dokumentuju, a u
skladu sa tim rezultatima preduzimaju se odgovarajuće korektivne akcije.
Specificira se tip informacija koje treba koristiti u procesu ispitivanja, tj.
in vivo ili simulacijom. Sve bezbednosne popravke (zakrpe), nadogradnje
i nove aplikacije treba ispitati pre ispitivanja promena konfiguracije na
usaglašenost.

- 550 -
2.2. Upravljanje promenama osnovne konfiguracija IKT sistema

U skladu sa politikom zaštite organizacije treba razviti,

dokumentovati i efikasno implementirati detaljne procedure za
dokumentovanje i odrţavanje tekuće, osnovne operativne konfiguracije
hardvera, programa i firmware IKT sistema.

Prva faza procesa kontrole osnovne konfiguracije obuhvata tekuće,

sveobuhvatno inventarisanje osnovnih komponenti konfiguracije sistema
(hardvera, programa i firmware), sa podacima o nazivu proizvoĊaĉa, tipu
i verziji i kontrolom usklaĊenosti podrške rada sistema sa planom za
upravljanje konfiguracijom. Kontroliše se adekvatnost zaštite rezervnih
(backup) kopija inventarisanih objekata. Zatim se kontroliše kompletnost
dokumentacije tekućih sistemskih programa, postojanje dijagrama
arhitekture i infrastrukture IKT sistema i dokumentacija o podešavanju
rutera, sviĉera, zaštitnih mreţnih kapija (Gateways), zaštitnih barijera
(firewalls) i drugih mreţnih ureĊaja za konekciju sa drugim sistemima.
Rutinski se proverava i valorizuje taĉnost tekućih informacija o
konfiguraciji sistema. Za distribuirane IKT sisteme, proverava se da li
postoji naredba za distribuiranu implementaciju sistemskih programa,
ukljuĉujući i obezbeĊenje svih lokacija sa potrebnim podacima.

2.3. Upravljanje promenama u IKT sistemu

U skladu sa politikom zaštite na nivou organizacije treba razviti,

dokumentovati i efikasno implementirati detaljne procedure za kontrolu
promena u IKT sistemu.

Mehanizmi za kontrolu promena odrţavaju kontrolu promena hardvera,

programa i alata (mehanizama i protokola) zaštite. Specifikaciju promena
u IKT sistemu priprema informatiĉar/programer, a revidira supervizor.
Komponente sistema (OS, pomoćni alati, aplikacije) ispituju se i
dokumentuju, a obezbeĊuje se akreditacija (odobravanje za rad) pre
uvoĊenja sistema u rad. Promene programa uvode se u rad samo na
osnovu dokumentovanog odobrenja korisnika i zvaniĉnih organa
organizacije za akreditaciju (odobravanje za operativni rad), koji su
odgovorni za razvoj sistema. Promene programa treba dokumentovati
tako da mogu biti praćene od trenutka davanje ovlašćenja za promene do
izdavanja konaĉne akreditacije za sertifikovanu (testiranu i verifikovanu)
promenu konfiguracije. Dokumentacija olakšava praćenje promena

- 551 -
konfiguracije, izradu specifikacija i funkcionalnih zahteva za promene.
Kontroliše se aţurnost dokumentacije za programe, hardver, radni
personal i korisnike IKT sistema kada se implementira novi ili
modifikovani sistem. Zahtev za implementaciju promena konfiguracije,
ukljuĉujući efektivne podatke o implementaciji, obezbeĊuje se i odrţava
u log datotekama na svakoj lokaciji.

2.4. Upravljanje promenama servisa za kontrolu pristupa

U skladu sa politikom organizacije treba razviti, dokumentovati i

efikasno implementirati detaljne procedure za nametanje restrikcija
pristupa koje treba da prate promene servisa za kontrolu pristupa
objektima IKT sistema.

Mehanizmi za restrikciju pristupa sistemskim i aplikativnim programima

IS i za korišćenje i monitoring korišćenja usluţnih i sistemskih programa
normalno su implementirani u proces kontrole pristupa. Odgovornosti za
korišćenje usluţnih i sistemskih programa jasno su definisane i
programeri ih dobro razumeju. Menadţment organizacije shvata
definisane odgovornosti za monitoring korišćenja programa. Privilegije
programera aplikacija da menja programe i podatke, ograniĉene su po
principu minimuma privilegija – samo za obavljanje posla i redovno se
revidiraju (npr. godišnje). Pristupi svim programima, ukljuĉujući
proizvodni kôd, izvorni kôd i ekstra kopije programa, zaštićeni su
mehanizmom za kontrolu pristupa i karakteristikama OS. Pristup
sistemskom programu ograniĉen je na mali broj zaposlenih, u skladu sa
odgovornostima na poslu. U skladu sa principom razdvajanja poslova,
programerima aplikacija i kompjuterskim operaterima specifiĉno se
zabranjuje pristup sistemskim programima, zbog moguće zloupotrebe.
Odobrenje i obrazloţenje od strane odgovarajućih organa organizacije za
pristup sistemskom programu dokumentuje se i odrţava. Privilegovano
korišćenje sistemskog i usluţnog programa revidiraju zvaniĉni organi
periodiĉno (npr. godišnje) i kontrolišu korektnost korišćenja dozvola za
pristup u skladu sa opisom radnih mesta i poslova korisnika.

- 552 -
2.5. Monitorisanje promena

U skladu sa politikom organizacije treba instalirati mehanizme i

razviti, dokumentovati i efikasno implementirati detaljne procedure za
monitorisanje promena IS i akcija koje preduzimaju privilegovani
korisnici.

Aktivnosti sistem programera monitorišu se i regularno revidiraju.

Korišćenje usluţnih programa loguju se na bazi izveštaja programa za
kontrolu pristupa ili informacija o odgovornostima na poslu.
Odgovarajući organ organizacije revidira sve pristupe programima IS
koji se loguju u log datoteku bezbednosno relevantnih kontrolnih
tragova.

2.6. Konfigurisanje minimuma servisa

U skladu sa politikom organizacije treba razviti, dokumentovati i

efikasno implementirati detaljne procedure za konfigurisanje sistema za
izvršavanje samo neophodnih operacija.

Funkcije i namena procesa i servisa dokumentuje se i odobrava od strane

zvaniĉnog lica organizacije. IS se periodiĉno revidira radi identifikovanja
i eliminisanja nepotrebnih servisa. Protokoli koji mogu uvesti
neprihvatljiv nivo rizika se onemogućavaju; zavisno od OS generalno se
onemogućava specifiĉan broj protokola ĉiju listu treba navesti u
dokumentaciji procesa. Raspoloţivi procesi/servisi sistema minimiziraju
se, kroz, [19]:
- instalaciju samo zahtevanih servisa
- restrikciju broja lica koji imaju pristup tim servisima, na bazi
koncepta najmanjeg broja privilegija i
- što pribliţnije odreĊivanje namene sistema kojeg podrţavaju
funkcionalnosti servera.

- 553 -
2.7. Kontrola i verifikacija bezbedne konfiguracije

U skladu sa politikom organizacije treba razviti, dokumentovati i

efikasno implementirati detaljne procedure za konfigurisanje i sistem
identifikatora za praćenje nivoa zaštićenosti IKT proizvoda koji ulaze u
sastav IS, u skladu sa najboljom praksom zaštite za podešavanje sistema
kontrola tih proizvoda, [13], [19].

Automatsko prepodešavanje bezbednosnih karakteristika proizvoda koji

se koriste u IKT sistemu podešeno je na najrestriktivniji naĉin rada,
kompatibilan sa zahtevima za rad sistema. Treba prepodesiti sve
pasvorde koje prodavci IKT proizvoda isporuĉuju. Startovanje,
iskljuĉivanje i obaranje IS konfigurišu se tako da obezbede da sistem
uvek ostane u bezbednom stanju. OS je konfigurisan tako da spreĉi
zaobilaţenje kontrola zaštite aplikativnih programa. Referentni dokument
organizacije kao što je Uputstvo za sistem zaštite, Uputstvo za
implementaciju sistema zaštite ili Kontrolna lista sistema zaštite primarni
su izvor za konfigurisanje sistema zaštite i uputstvo za implementaciju i
razvoj novih IKT proizvoda, OS i hostovanih aplikacija. Ako referentni
dokumenti organizacije nisu na raspolaganju, prihvatljivi su drugi izvori
kao što su proizvoĊaĉka uputstva, baze znanja na Internetu i druga
literatura. Kada su na raspolaganju odgovarajući alati, bezbednost
konfiguracije IKT sistema vrednuje se automatski, korišćenjem
automatskih alata za praćenje indikatora kvaliteta sistema zaštite.

2.8. Upravljanje konfiguracijom raĉunarske mreţe

U skladu sa politikom organizacije treba razviti, dokumentovati i

efikasno implementirati detaljne procedure za konfigurisanje parametara
mreţe tako da maksimalno smanje izloţenost mreţe napadima.

Mreţe se na odgovarajući naĉin konfigurišu da bi se adekvatno zaštitili

pristupni putevi izmeĊu umreţenih IS. Graniĉni interfejs svakog IS
konfiguriše se tako da adekvatno obezbedi da su zabranjeni svi dolazni i
odlazni komunikacioni protokoli, servisi i komunikacije, koji nisu
eksplicitno dozvoljeni. Odnosi poverenja izmeĊu hostova i spoljnih
entiteta na odgovarajući naĉin se redukuju na minimalni nivo neophodan
da se izvršavaju poslovni zadaci organizacije. Jasno su opisani
bezbednosni atributi svakog mreţnog servisa.

- 554 -
2.9. Politika zaštite privatnosti

U skladu sa politikom organizacije treba razviti, dokumentovati i

efikasno implementirati detaljne procedure koje indiciraju da je zaštita
privatnosti korisnika prioritet u organizaciji.

Politika privatnosti treba da se implementira na odgovarajućim

sistemima, ukljuĉujući web server/lokaciju organizacije.

2.10. Ograniĉavanje tipova saobraćaja

U skladu sa politikom organizacije treba razviti, dokumentovati i

efikasno implementirati detaljne procedure za konfigurisanje IKT sistema
tako da kontroliše specificirane tipove saobraćaja.

Unutar IS organizacije treba zabraniti saobraćaj koji obuhvata trenutno

slanje poruka prema i od klijenata koji su nezavisno konfigurisani,
krajnjim korisnicima i onima koji saraĊuju sa provajderima javnih
servisa. Dolazni i odlazni saobraćaj trenutnog slanja poruka blokira se na
granici IS (što ne ukljuĉuje ovlašćen saobraćaj) za personalno korišćenje.
Unutar IS organizacije zabranjuje se i audio saobraćaj i Internet protokoli
prema i od radne stanice IP telefonskih klijenata koji su nezavisno
konfigurisani sa krajnjim korisnikom. Dolazni i odlazni VoisIP saobraćaj
individualno konfigurisan blokiran se na granici IS (što ne ukljuĉuje
ovlašćen saobraćaj).

U cilju boljeg razumevanja procesa upravljanja konfiguracijom i

potencijalnih pretnji za ovu komponentu zaštite, razvijena je Vežba GIII
P6A.

- 555 -
3. REZIME

Poverenje koje se stiĉe upravljanjem konfiguracije od koristi je za

sve sisteme. Za sisteme zaštite bez obzira ne bezbednosni nivo (EAL)
zahteva se da sve promene konfiguracije budu praćene, kontrolisane,
dokumentovane i verifikovane, odnosno da proces upravljanja
konfiguracijom bude implementiran.

Uspešno upravljanje konfiguracijom izgraĊuje se na ĉetiri glavna

principa upravljanja: identifikacija, upravljanje konfiguracijom,
registrovanje stanja konfiguracije i revizija (auditing) procesa
upravljanja konfiguracijom.

Kroz ispunjavanje ciljeva ovih principa proces upravljanja

konfiguracijom moţe odrţavati kontrolu sistema zaštite od neovlašćenih
izmena koje mogu izazvati loše funkcionisanje ili zaobilaţenje
mehanizama zaštite.

Dobar plan upravljanja konfiguracijom treba da poĉne sa definisanjem

ciljeva, obima i procedura za upravljanje konfiguracijom. Uspeh procesa
upravljanja konfiguracijom zavisi od preciznosti (taĉnosti) izvršavanja
razvijenih procedura. Promene moraju biti identifikovane i precizno
registrovane, a po završetku promena detaljno dokumentovane i testirane.

Upravljanje konfiguracijom obezbeĊuje kontrolu i registrovanje tragova

svih promena u sistemu. Promene koje su u toku moraju biti
monitorisane pregledom informacija dobijenih iz evidencije podataka o
promenama, da bi se evaluirao uticaj na druge delove sistema.

Vaţan deo uspeha plana za upravljanje konfiguracijom je da odgovorna

lica moraju striktno sprovoditi procedure da bi odrţavali aţurnim svu
dokumentaciju i status promena. Striktnim sprovoĊenjem plana smanjuje
se mogućnost implementacije nepotrebnih promena ili dupliranja
promena.

U planu za upravljanje konfiguracijom treba da budu razvijene i

dokumentovane procedure, što obezbeĊuje da se upravljanje
konfiguracijom izvršava na specificiran naĉin. Proces upravljanja
promenama konfiguracije optimalno obuhvata sledeće procedure: izrada
plana za upravljanje promenama konfiguracije, upravljanje promenama

- 556 -
osnovne konfiguracije računarskog sistema, upravljanje promenama u
IKT sistemu, upravljanje promenama servisa za kontrolu pristupa,
monitorisanje promena konfiguracije, konfigurisanje minimuma servisa,
kontrola i verifikacija bezbedne konfiguracije, upravljanje
konfiguracijom računarske mreže, politika zaštite privatnosti i
ograničavanje tipova saobraćaja.

- 557 -
4. KLJUĈNI TERMINI

Registrovanje podataka o konfiguraciji (Configuration Accounting):

Registrovanje (snimanje) i izveštavanje o opisu objekata konfiguracije i
svih promena od osnovne konfiguracije (baseline).
Revizija procesa upravljanja konfiguracijom (Configuration Audit):
nezavisna revizija sa ciljem da se izvrši procena usklaĊenosti sa
uspostavljenim zahtevima, standardima i osnovnom konfiguracijom.
Kontrola konfiguracije (Configuration Control): proces kontrole
modifikacija projekta sistema, hardvera, softvera i dokumentacije koja
obezbeĊuje dovoljnu garanciju da je sistem zaštićen od uvoĊenja
nepropisnih modifikacija pre, u roku i posle implementacije sistema.
Identifikacija konfiguracije sistema (Configuration Identification):
identifikovanje konfiguracije sistema kroz zadatke projektovanja,
razvoja, testiranja i funkcionisanja.
Objekat konfiguracije (Configuration Item): najmanja komponenta
hardvera, softvera, firmware i dokumentacije ili bilo kojeg njihovog
diskretnog dela, koji sistem upravljanja registruje i prati
Upravljanje konfiguracijom (Configuration Management): upravljanje
promenama sistemskog hardvera, softvera, firmware, dokumentacije,
metoda testiranja i dokumentacije za testiranje od faze razvoja do kraja
operativnog ţivota sistema.

- 558 -
5. LITERATURA

1. American Bar Association Privacy & Computer Crime

Committee Section of Science & Technology Law,
International Startegy for Cyberspace Security,
www.abapccc.com, august 2003.
2. Australian Communications-Electronic Security Instruction 33,
Security Handbook, www.acsi.com, 2002.
3. Carrol M.J., Computer Security, Butterworth-Heinemann, 1997.
4. David J. McKerrow, Canadian Handbook on Information
Technology Security, www.canadacss.com, 1999.
5. Domarev V.V.,Защита информации и безопасность
компьютерных систем, 1997.
6. Dr. Rayford B. Vaughn, Jr, A practical approach to sufficient
INFOSEC, Mississippi State University, Department of
Computer Science, vaughn@cs.msstate.edu, 2002.
7. GAISP –Generally Accepted Information Security Principles,
www.gaisp.org, 2003.
8. IEC/ISO 17799 Security Standard overview,
http://www.securityauditor.net/iso17799/what.htm, 2005.
9. International Federation of Accountants, Managing Security of
Information, http://www.ifa.org, 1998.
10. ISO/IEC 17799:2000, Information Technology – Code of
practice for information security management,
http://www.iso.17799.org, 2003.
11. BSI (Federalni IS Nemaĉke), IT Baseline Protection Manual,
http://www.bsi.bund.de/gshb, juli 2000.
12. IT Governance Institute, COBIT (Control Objectives for
rd
Information and related Technology) 3 Edition, 2000,
www.ITgovernance.org, www.isaca.org.
13. NATIONAL COMPUTER SECURITY CENTER, A Guide to
Understanding Configuration Management in Trusted Systems,
NCSC-TG-006-88, http://www.ncscnist.gov/publications, 1988.
14. NIST SP 800-12, An Introduction to Computer Security: The
NIST Handbook, http://www.nist.gov/publications,, verzija
2004.
15. Patrick J., Organizational Information Security From Scratch –
A Guarantee For Doing It Right, SANS Institute,
http://www.sans.org, 2000.

- 559 -
17. Purser S., A practical guide to managing information security,
Artech House, Boston, London, http://www.artechhouse.com,
2005.
18. Ross R., Katzke S., NIST SP 800-53, A, B, C, Recommended
Security Controls for Federal IS,
http://www.csrc.nist.gov/publications, 2005.
19. Russel D., Gangemi G.T. sr, Computer Security Basics,
O‘Reilly and Ass., SAD, 1992.
20. Ruth A, Hudson K., Sertificat Security +, MicrosoftCo., CET
Beograd, 2004.

- 560 -
7. UPRAVLJANJE KOMPJUTERSKIM INCIDENTOM

0. UVOD

Po završetku ovog poglavlja razumećete:

- razliku kompjuterskog događaja i incidenta

- politiku i procedure upravljanja incidentom
- glavne kategorije kompjuterskog incidenta
- proces upravljanja kompjuterskim incidentom
- procese saniranja posledica i analize iskustava

Dobro je poznato da su IKT sistemi podloţni širokom opsegu

napada i zloupotreba – od korupcije datoteka do virusa i razornog uticaja
prirodnih katastrofa. Neke od ovih zloupotreba mogu se fiksirati kroz
standardne IKT operativne procedure (npr., greškom izbrisana datoteka
restauracijom iz rezervne kopije). Drugi štetni dogaĊaji - kompjuterski
incidenti nastaju zbog namernih malicioznih tehničkih aktivnosti iznutra-
nezadovoljni zaposleni, spolja-hakera, krakera, vandala, mogu imati
nepredvidljive posledice i potrebno ih je kontrolisati.

Definicija bezbednosnog kompjuterskog incidenta je priliĉno fleksibilna

kod većine autora i varira u zavisnosti od organizacije i IKT
okruţenja.Termin tehničke aktivnosti u IKT odnosi se generalno na
bezbednosne incidente koji bez struĉno-tehniĉkog odgovora mogu naneti
ozbiljne štete u sistemu. Suoĉene sa ovakvim incidentom, većina
organizacija preduzima ad-hoc mere. Praksa reaktivne zaštite potvrdila je
da je rentabilno razviti stacionarne kapacitete za brzo otkrivanje i
reagovanje na incident. U proaktivnom sistemu zaštite verovatnoća
spreĉavanja štetnog uticaja incidenta znatno je veća.

Većina bezbednosnih kompjuterskih incidenata utiĉe na funkcionisanje

organizacije. U najvećem broju sluĉajeva, uticaj je relativno mali, a
trajanje incidenta relativno kratko. MeĊutim, sa porastom zavisnosti
poslovanja od IKT sistema, uticaj incidenta raste, a tolerancija na bilo
kakve smetnje se smanjuje. Ipak, ima mnogo naĉina da organizacija
redukuje uticaj ili ublaţi posledice incidenta. Generalno, ove aktivnosti
nazivaju se planiranje vanrednih dogaĊaja, a odnose se na kritiĉne misije
ili poslovne funkcije. Upravljanjem kompjuterskim incidentom tesno je
povezano sa aktivnostima planiranja vanrednih dogaĊaja i drugim

- 561 -
upravljaĉko-operativnim kontrolama, ali ih treba odvojeno razmatrati da
bi se smanjila kompleksnost upravljanja sistemom zaštite. U kontekstu
šireg programa zaštite, organizacija mora planirati razvoj kapaciteta za
upravljanje kompjuterskim incidentom, u sklopu razvoja kapaciteta za
korisniĉku podršku, ili kao deo opšte podrške za rad IKT sistema.

Proces upravljanja kompjuterskim incidentom obuhvata dve kljuĉne faze:

uspostavljanje kapaciteta za upravljanje incidentom-politika i procedure,
formiranje interventnog tima, upravljanje, analiza iskustava i upravljanje
specifičnim tipovima incidenata-odbijanje izvršavanja servisa (DoS),
maliciozni napadi (virusi, crvi, Trojanci i.t.d.), neovlašćeni pristup,
nepropisno korišćenje, kombinovani napad i dr.

- 562 -
1. KOMPJUTERSKI DOGAĐAJ I KOMPJUTERSKI INCIDENT

Kompjuterski dogaĎaj je bilo koje uoĉljivo dešavanje u sistemu ili

mreţi. Kompjuterski incident je dogaĊaj sa negativnim posledicama, kao
što su pad sistema, zagušivanje mreţnog saobraćaja, neovlašćeno
korišćenje privilegija, aktiviranje malicioznih kodova za destrukciju
(izmenu, oštećenje, uništavanje) podataka i sl. Upravljanje
kompjuterskim incidentom obuhvata samo one negativne dogaĊaje koji
se odnose na sistem zaštite i iskljuĉuju vanredne negativne dogaĊaje koji
su posledica prirodnih katastrofa, prekida elektriĉnog napajanja i sl.

Definicija kompjuterskog incidenta evoluirala je od bezbednosno

relevantnog dogaĊaja koji dovodi do gubitka raspoloţivosti, poverljivosti
i integriteta podataka, do proširene definicije kompjuterskog incidenta u
savremenom kompjuterskom okruţenju: povreda ili imanentna pretnja za
povredu politike zaštite (npr. provajder zaštite dostavi novu definiciju
virusa koji se brzo širi Internetom), povredu primene politike i standarda
prakse zaštite, [7].

Ĉinjenica da su incidenti neizbeţni zahteva da se koriste efikasne

procedure reagovanja u upravljanja incidentom. Pošto incident
predstavlja nepoznatu pretnju, takva procedura treba da implementira
struktuiran pristup da bi se incident stavio pod kontrolu. Brojne tehniĉke
specifikacije kompjuterskih incidenata dostupne su na web lokaciji
CERT DFN (Deutsches ForschungsNetz), [3].

Svi kompjuterski incidenti nisu bezbednosno relevantni, pa je vaţno sa

sigurnošću identifikovati izvor i stvarno postojanje incidenta. Od brojnih
kategorizacija, za većinu organizacija moţe se primeniti podela incidenta
na one koji:

1. ne predstavljaju glavnu pretnju sistemu i organizaciji i koji

2. mogu izazvati zaustavljanje poslova organizacije.

Neki tipovi kompjuterskih incidenata mogu se nazvati katastrofalnim,

kao što su uspešan ili potencijalno uspešan napad na Internet firewall,
poslovni IKT sistem, sistem zaštite na bilo kojem nivou, kompromitacija
poverljivih podataka i sl. Vaţno je izvršiti paţljivu trijaţu incidenata po
znaĉaju za funkcionisanje celog poslovnog sistema. U procesu inicijalne

- 563 -
istrage incidenta treba pretpostaviti da je sistem zaštite probijen i utvrditi
štetu. Programa za upravljanje incidentom treba da ukljuĉuje definisanje
adekvatnih mera zaštite, prioriteta za odgovor na incident i prioriteta za
oporavak sistema, koristeći identifikovane elemente ranjivosti sistema.

U praksi zaštite kompjuterski incident se retko na vreme prijavljuje, jer

ga pokušavaju rešavati sopstvenim snagama, sakriti od javnosti i sl. U
odreĊenim sluĉajevima izveštavanje o incidentu mora biti izuzetno brzo:
gde je šteta oĉigledna, postoji potencijalna šteta, kompromitacija ili
zakonska odgovornost, ako se incident ne prijavi.

- 564 -
1.2. Politike i procedure za upravljanje incidentom

Politika upravljanja incidentom u većini organizacija obuhvata iste

kljuĉne elemente, bez obzira da li su kapaciteti za upravljanje incidentom
interni ili iznajmljeni, [7]:

 izjava menadţmenta o angaţovanju,

 namena i ciljevi politike,
 obim i granice politike,
 identifikacija incidenta i njegove posledice u kontekstu
organizacije,
 definisanje organizacione strukture uloga i odgovornosti
interventnog tima,
 zahtev za izveštavanje o odreĊenim tipovima incidenata,
 prioriteti ili rangiranje teţine incidenta,
 merenje performansi kapaciteta za upravljanje incidentom,
 naĉin i forma izveštavanja.

Procedure za upravljanje incidentom u formi Standardne operativne

procedure (SOP), zasnivaju se na Politici upravljanja incidentom i
detaljno objašnjavaju specifiĉnih aktivnosti tehniĉkih procesa, tehnike,
ĉek liste i formulare, koje koristi interventni tim. Treba da budu
sveobuhvatne i dovoljno detaljne da obezbede prioritetne akcije
interventnog tima i smanje greške zbog tempa i pritiska koji prate tipiĉan
proces reagovanja na incident. Pre distribucije svim ĉlanovima tima treba
testirati i verifikovati efektivnost SOP, izvršiti obuku i pripremiti
dokument SOP kao instrukcija za praktiĉnu primenu. Primer kljuĉnih
elemenata SOP za odreĊivanje karaktera kompjuterskog incidenta dati je
u PRILOGU III 7A, [4].

- 565 -
1.3. Kategorije bezbednosnog kompjuterskog incidenta

Incident se moţe dogoditi na bezbroj naĉina, pa nije praktiĉno

razvijati sveobuhvatne korak-po-korak procedure sa instrukcijama za
upravljanje incidentom. Generalno organizacija se moţe pripremi za
upravljanje sa bilo kojim tipom incidenta, a specifiĉno sa prepoznatljivim
tipovima incidenata. U interesnoj zajednici zaštite još uvek nema
konsenzusa o najboljoj taksonomiji kompjuterskog incidenta. MeĊu
brojnim podelama, korisna je kategorizacija na bazi primarnih kategorija
napada, koja nije sveobuhvatna ni definitivna, nego pre osnovno uputstvo
za upravljanje incidentom, [7], [10]:

1. Odbijanje izvršavanja servisa (DoS), napadi koji iscrpljuju

resurse i spreĉavaju ili slabe kvalitet ovlašćenog korišćenja
sistema;
2. Maliciozni kôdovi (virusi, crvi, Trojanci i dr.), koje proizvode
maliciozni entiteti da inficiraju neki host:
3. Neovlašćeni pristup, logiĉki ili fiziĉki, nekom objektu IS;
4. Nepropisno korišćenje usvojene politike prihvatljivog korišćenja
IKT sistema;
5. Kombinovani napad obuhvata dva ili više faktora pretnji koji
izazivaju incident.

Neki incidenti mogu se svrstati u više od jedne kategorije, pa interventni

tim treba da izvrši dodatnu kategorizaciju (npr., prema mehanizmu
prenosa Trojanac za neovlašćeni pristup je kombinovani incident, jer se
koriste dva prenosna mehanizma).

- 566 -
1.4. Nagoveštaji kompjuterskog incidenta

Najveći izazov u procesu upravljanja incidentom je pouzdano

donošenje odluke da li se incident dogodio i, ako jeste, kojeg je tipa i
intenziteta i kolika je veliĉina problema. Ovaj problem je još teţi, jer ga
tipiĉno ĉini kombinacija sledeća tri faktora, [4]:

1. Incidente mogu detektovati razna sredstva sa razliĉitim nivoima

taĉnosti i pouzdanosti: mreţni i host IDS/IPS sistemi, antivirusni
programi i analizatori log datoteka i izveštaji korisnika o
problemu.
2. Potencijalni znaci da se incident dogodio brojni su (napadaĉ koji
skenira 10 web servera moţe generisati nekoliko hiljada IDS
alarma).
3. Potrebno je specijalistiĉko tehniĉko znanje i veliko iskustvo za
propisnu i efikasnu analizu podataka koji se odnose na incidente.

Nagoveštaji nekog incidenta spadaju u jednu od dve kategorije:

predznaci i indikatori.

Predznak je nagoveštaj da se neki incident moţe dogoditi u bliskoj

budućnosti. Na primer, IDS senzor moţe detektovati neobiĉnu aktivnost
skeniranja porta usmerenu na grupu hostova, koja se dešava neposredno
pred DoS napad na hostove. Predznaci incidenta mogu biti: log datoteka
u web serveru pokazuje korišćenje skenera ranjivosti Web servera,
najavljena nova iskoristivost koja pogaĎa ranjivost mail servera
organizacije i pretnja grupe hakera da će napasti organizaciju i.t.d..

Naravno, svaki napad se ne moţe detektovati kroz predznake. Neki

napadi nemaju predznake, dok drugi generišu predznake koje
organizacija ne uspeva detektovati. Ako se predznaci detektuju,
organizacija ima priliku da izmeni sistem zaštite i ruĉno ili automatski
spreĉi napad na objekat IKT sistema.

- 567 -
Indikator je znak da se neki incident vrlo verovatno dogodio, ili se
upravo dogaĊa. Postoji više tipova indikatora incidenta, a tipiĉni primeri
su:

 mreţni IDS alarmira kada je neki bafer preplavljen pokušajima

napada na FTP server,
 antivirusni program alarmira kada detektuje da je host inficiran sa
nekim crvom,
 pad web servera,
 korisnici se ţale na spor pristup hostu na Internetu.
 korisnik naziva kol centar da prijavi preteću e-mail poruku,
 host registruje promenu auditing konfiguracije u svojoj log datoteci,
 aplikacija loguje više propalih pokušaja pristupa udaljenog
nepoznatog korisnika,
 e-mail administrator vidi veliki broj povezanih e-mail-ova sa
sumnjivim sadrţajem,
 administrator mreţe uoĉava neobiĉna odstupanja od tipiĉnog
mreţnog toka i.t.d..

Predznaci i indikatori incidenta identifikuju se korišćenjem više razliĉitih

izvora, od kojih su najĉešći softverski alarmi zaštite raĉunara, log
datoteke, javno raspoloţive informacije i ljudi. U PRILOGU III 7B u
Tabeli 3.2. prikazani su najĉešći izvori indikatora i predznaka
kompjuterskih incidenata za svaku kategoriju incidenata, [4].

- 568 -
2. UPRAVLJANJE KOMPJUTERSKIM INCIDENTOM

Cilj procesa upravljanja bezbednosnim kompjuterskim

incidentom je da se ograniĉi mogućnost upada u sistem na kontrolisanom
nivou rizika kroz: efikasnu preventivnu zaštitu, testiranje otpornosti
sistema na upad, skeniranje ranjivosti sistema i detekciju incidenta
(IDS/IPS), kao i da se olakša istraţni postupak kada se incidenta već
dogodio. Proces reagovanja na kompjuterski incident moţe se podeliti u
nekoliko faza, zavisno od organizacije koja ga planira i izvršava, [10].
Proces upravljanja bezbednosnim kompjuterskim incidentom ima 4
kljuĉne faze [7]:

1. priprema (preventivna zaštita, izbegavanje incidenta);

2. detekcija i analiza incidenta,
3. saniranje posledica i oporavak sistema i
4. analiza iskustava.

Na slici Sl. 2.1. prikazan je funkcionalni model ţivotnog ciklusa procesa

upravljanja bezbednosnim incidentom, [4].

SANIRANJE
DETEKCIJA I POSLEDICA I ANALIZA I
PRIPREMA
ANALIZA OPORAVAK ISKUSTAVA
SISTEMA

Sl. 2.1. Ţivotni ciklus procesa upravljanja bezbednosnim

incidentom

- 569 -
2.1. Pripremna faza

Metodologija upravljanja incidentom istiĉe pripremnu fazu u

kojoj se preduzimaju preventivne mere za sprečavanje incidenata,
obezbeĊenjem adekvatnog sistema zaštite i uspostavlja interventni tim
(CIRT - Computer Incident Response Team) i priprema za brzo
reagovanje na incident, [1]. Proces uspostavljanja CIRT tima opisan je u
PRILOGU III 7C.

Preventivne mere za sprečavanje incidenata svakog tipa obuhvataju

razvoj i implementaciju programa zaštite u celini. Primarni ciljevi
razvoja kapaciteta za upravljanje kompjuterskim incidentom su brzo
reagovanje na incidente, saniranje štete i oporavak sistema. Kapaciteti za
upravljanje kompjuterskim incidentom moraju biti preventivno instalirani
i spremni da po potrebi obezbede: brzo reagovanje na sumnjive
aktivnosti, koordinaciju aktivnosti lica ukljuĉenih u spreĉavanje ili
uklanjanje posledica kompjuterskog incidenta, izveštavanje o incidentu i
pomoć za oporavak sistema. Kapaciteti kao što su obuĉeni personal i
antivirusni programi,.

Kapaciteti za upravljanje kompjuterskim incidentom, takoĊe, pomaţu

organizaciji u spreĉavanju ili minimizaciji potencijalne štete od
kompjuterskog incidenta. Skupljaju se podaci o incidentima i
korektivnim akcijama, skladište u bazu znanja, zatim se analiziraju i
formira se obrazac ponašanja (profil) napadaĉa, na primer, najĉešćeg tipa
virusa, najuspešnije korektivne mere i akcije i najĉešće napadanog
sistema. Proaktivni sistemi zaštite obezbeĊuju efikasnu i efektivnu
zaštitu od poznatih, ali i nepoznatih dinamiĉki promenljivih pretnji,
znatno uspešnije od postojećih reaktivnih sistema zaštite i rentabilnije su
od oporavka sistema i otklanjanja štete. U PRILOGU III 7D date su
preporuke meĊunarodnih interventnih timova za kompjuterske incidente
(CIRT i CERT tipa) za preventivno poboljšanje prakse zaštite IKT
sistema.

Interventni tim za upravljanje kompjuterskim incidentom, iako nije

odgovoran za spreĉavanje incidenata, ĉini glavnu komponentu kapaciteta
za upravljanje incidentom. Ekspertska znanja ĉlanova tima dragocena su
kao izvor preporuka za poboljšanje sistema zaštite. Ĉlanovi tima za
upravljanje kompjuterskim incidentom, tipiĉno su specijalisti za mreţnu
tehniku, platforme i komunikacije i treba da imaju specifiĉna znanja,

- 570 -
veštine i sposobnosti za upotrebu neke tehnologije za upravljanje
incidentom, timski rad i efektivnu komunikaciju sa razliĉitim vrstama
korisnika i da su na raspolaganju 7x24 sata i fiziĉki raspoloţivi na
lokaciji intervencije što je moguće brţe.

Modeli struktura interventnog tima za upravljanje kompjuterskim

incidentom mogu se svrstati u tri kategorije, [6], [7]:

1. Centralni interventni tim, upravlja incidentima u celoj organizaciji,

efikasan za male i veće organizacije sa malom distribucijom objekata
IKT sistema.
2. Distribuirani interventni tim, upravlja incidentom u posebnim
logiĉnim ili fiziĉkim segmentima organizacije, ali je deo centralnog
entiteta i konzistentnog procesa upravljanja incidentom.
3. Koordinacioni interventni tim koji savetodavno vodi rad drugog tima.

Model popune interventnog tima za upravljanje kompjuterskim

incidentom (tipiĉan):

- interno zaposleni, sa ograniĉenom tehniĉko-administrativnom

pomoći spolja;
- delimično iznajmljene usluge spoljnih saradnika za monitoringa
IDS senzora, firewalls-a i drugih dislociranih ureĊaja sistema
zaštite, ili saniranje posledica incidenata, posebno većeg
intenziteta i razmera i
- potpuno iznajmljen tim u organizacijama bez dovoljno
kvalifikovanih u zaštiti.

Efektivni i efikasni kapaciteti za upravljanje kompjuterskim incidentom

treba da imaju nekoliko kljuĉnih karakteristika:

 razumevanje obima i granica procesa upravljanja i komponenti

kapaciteta,
 edukativnu komponentu,
 sredstva za centralizovano upravljanje (komunikaciju i izveštavanje),
 struĉne kadrove za primenjene tehnologije,
 dobre veze sa drugim entitetima koji pomaţu u upravljanju
incidentom (po potrebi).

- 571 -
Obim i granice kapaciteta za upravljanje kompjuterskim incidentom ne
obuhvataju uvek celu organizaciju. Sastavne komponente kapaciteta za
upravljanje kompjuterskim incidentom su, pored tehnoloških i korisnici
IKT sistema i menadţeri programa.

Obuka korisnika ima za cilj da se smanji kompleksnost, poveća

korisniĉka prihvatljivost kapaciteta za upravljanje incidentom i obezbedi
sveobuhvatno izveštavanje. U PRILOGU III 7E prikazan je uzorak
uputstva za izveštavanje po prioritetima.

Centralizovane komunikacije, izveštavanje i upravljanje obezbeĊuju

efikasno i efektivno upravljanje kompjuterskim incidentom. Uspeh
odgovora na kompjuterski incident zavisi od blagovremenosti
izveštavanja o incidentu. Ako je bezbednosni incidenti hakerski napad,
treba koristiti kriptozaštićen sistem za izveštavanje, analizu i ĉuvanje
sadrţaja informacija o incidentu.

Tehnologija u procesu upravljanja incidentom obuhvata specifiĉne

forenziĉke alate od kojih su mnogi raspoloţivi na Internetu. U
PRILOGU III 7F (Tabela 3.1), prikazani su neki alati i resursi za
upravljanje kompjuterskim incidentom. Većina interventnih timova
formira prenosni komplet za istragu kompjuterskog incidenta, u kojem se
nalazi većina alata iz T.3.1, forenziĉki laptop raĉunar, sa odgovarajućim
programima (n.p.r. mreţni skener, snifer paketa, alati za forenziĉku
akviziciju i analizu digitalnih podataka), ureĊaji za bekapovanje, ĉisti
elektronski mediji, baziĉna oprema i kablovi za umreţavanje, mediji sa
OS i aplikacijama i bezbednosne zakrpe, [4].

- 572 -
2.2 Detekcija i analiza incidenta

Detektori upada (Intrusion Detector Systems - IDS ili IPS-

Intrusion Protection Systems) u IKT sistem osnovni su alati za detekciju
povrede sistema zaštite. Preventivni alati su oni koji obavljaju inicijalnu
evaluaciju konfiguracije sistema, a detektorski alati obezbeĊuju kontrolu
svake neregularne promene stanja u sistemu. Primeri takvih alata su
brojni: Intruder Alert (ITA), AXENT Technologies - detektor napada na
platformu, RealSecure, ISS - detektor za napade na komunikacije i.t.d.
Ovakvi alati prikupljaju informacije o napadu i napadaĉu, koje su korisne
za forenziĉku istragu i analizu. Dobro upravljanje upadom u IKT sistem,
preventiva je svih potencijalnih problema i daje šansu da se pokrene
istraga o incidentu. Detekcija i analiza incidenta mogu uvek biti
predznaci ili indikatori pojave incidenta, ako su precizni, što naţalost nije
uvek sluĉaj. Naime, IDS sistemi proizvode veliki broj laţnih pozitivnih
alarma, ili netaĉnih indikacija. Ĉak i kada je neka indikacija taĉna, ne
znaĉi da se incident dogodio, što pokazuje zašto su detekcija i analiza
incidenata tako teški. Pametno je sumnjati u svaki incident i smatrati da
se neki incident dogaĊa, sve dok se ne pojave indikatori da se ne dogaĊa.

Za efikasniju i efektivniju inicijalnu analizu incidenta preporuĉuje se

proces inicijalne korporacijske istrage kompjuterskog incidenta i
procedura u PRILOGU III 7G, [4].

U PRILOGU III 7H ukratko je opisan kompleksni proces korporacijske

istrage kompjuterskog incidenta koji obuhvata kljuĉne faze: pripremnu i
podnošenje zahteva za istragu kompjuterskog incidenta, akviziciju i
rukovanje sa digitalnim dokazima i identifikaciju napadača.

- 573 -
2.3. Saniranje posledica i oporavak sistema

Strategija saniranja posledica incidenta varira i zavisi od tipa incidenta

(npr., virusne infekcije preko e-pošte, od mreţno distribuiranog DoS
napada). Veoma je preporuĉljivo da organizacije razviju posebne
strategija saniranja posledica najmanje od glavnih kategorija incidenata i
za sve glavne tipove incidenata. Da bi se brţe donosile odluke treba
eksplicitno dokumentovati kriterijume za odreĊivanje odgovarajuće
strategije za saniranje incidenta, koji ukljuĉuju:

 Potencijalna oštećenja i kraĊu objekata;

 Obavezu ĉuvanja dokaza za forenziĉku analizu i veštaĉenje;
 Raspoloţivost servisa (npr. umreţenost, servisi za spoljne
korisnike);
 Vreme i resurse potrebne za implementaciju strategije;
 Efektivnost strategije (npr. delimiĉno sanira incident, potpuno
sanira incident);
 Trajanje rešenja (npr. hitna mera, koja se mora ukloniti za 4 sata;
privremena mera, koja se uklanja za dve sedmice; permanentno
rešenje) i dr.

U fazi oporavka, treba eliminisati preostale komponente incidenta,

izbrisati maliciozne kôdove i dezaktivirati probijene korisniĉke naloge.
Faza oporavka moţe ukljuĉiti restauraciju sistema iz rezervnih kopija,
zamenu kompromitovanih datoteka sa ĉistim verzijama, instalaciju
zakrpa, izmenu pasvorda i ojaĉanje zaštite perimetra mreţe (npr.
prepodešavanje politika firewalls, renoviranje kontrolne liste pristupa
graniĉnog rutera) i podizanje na viši nivo sistema logovanja ili
monitoringa mreţe. Na Internetu su na raspolaganju brojni resursi za
oporavak sistema, koji se detaljno opisuje u SOP OS.

- 574 -
2.4. Analiza iskustava

Analiza iskustava iz upravljanja incidentima, iako je najvaţnija, ĉesto

se najĉešće zanemaruje. U fazi analize iskustava procesa upravljanja
incidentom treba razmatrati sledeća pitanja:

 Šta se taĉno desilo i u koje vreme?

 Koliko dobro su se ponašali menadţment i zaposleni u saniranju
incidenta?
 Da li je sprovedena dokumentovana procedura?
 Da li je procedura adekvatna?
 Koje su informacije bile potrebne neposredno po izbijanju incidenta?
 Da li su preduzete neke akcije koje mogu spreĉiti oporavak?
 Šta bi zaposleni i menadţment sledeći put uradili drugaĉije sa sliĉnim
incidentom?
 Koje korektivne akcije mogu spreĉiti sliĉne incidente u budućnosti?
 Koji su alati/resursi potrebni za detekciju, analizu i saniranje novog
incidenta?

Mali incidenti ne zahtevaju posebnu analizu u post-incidentnom periodu,

osim ako incident nije izazvao novi i nepoznati metod napada. Ako se
dogodi ozbiljan napad, uvek je korisno izvršiti detaljnu
multidisciplinarnu analizu na sastanku interventnog tima. Na takvu
analizu treba pozvati sve uĉesnike u procesu upravljanja incidentom, a i
one od kojih se oĉekuje buduća saradnja. Korisno je pripremiti dnevni
red analize, iskusne moderatore za voĊenje analize i dokumentovati
glavne taĉke analize, [4].

Kompletiran izveštaj analize incidenta koristi se za: obuku, aţuriranje

politike/procedura za upravljanje incidentom, popravku procedura,
aţuriranje dokumenata za upravljanje incidentom, izradu pojedinaĉnih
analitiĉkih izveštaja za svaki incident, izradu vremenske linije
hronologije dogaĊaja iz log datoteka za dokazni postupak i.t.d.
Na bazi prethodnih izveštaja i oĉekivanja od skupljenih podataka,
organizacija odluĉuje koji se podaci o incidentima skupljaju. Interventni
tim se mora usmeriti na skupljanje podataka koji su relevantni za akcije
upravljanja incidentom.

- 575 -
Podatke koji se odnose na incidente moguće je meriti/ocenjivati sa:

 Brojem saniranih incidenata, mera relativnog obima rada, a ne

kvaliteta tima, sa odvojenim podacima za svaku kategoriju
incidenata; nije posebno vredna, jer zavisi od definicije
»incidenta« pa podaci o broju incidenata mnogo ne znaĉe.
 Utrošenim vremenom po incidentu kao: ukupno vreme rada na
incidentu, vreme od pojave do saniranja, vreme trajanja svake
faze upravljanja i vreme reakcije od inicijalnog izveštaja.
 Objektivnom procenom svakog incidenta, koja odreĊuje
efektivnost akcija, npr: pregled logova, obrazaca, izveštaja i druge
dokumentacije o incidentu; pregled predznaka i indikatora
incidenta, odreĊivanje eventualne štete, odreĊivanje da li je
stvarni uzrok incidenta identifikovan, proraĉun pribliţnog
finansijskog gubitka od incidenta i identifikovanje mera za
spreĉavanje novih sliĉnih incidenata.
 Subjektivna procena svakog incidenta ĉlanova interventnog tima i
tima u celini,
 Periodična kontrola programa za upravljanje incidentom i to
najmanje:
politike, procedure i standard najbolje prakse upravljanja
incidentom, alate i resurse, model i strukturu tima,
dokumentaciju, izveštaj i mere uspeha.

Čuvanje (zadržavanje) dokaza treba da definiše Politika upravljanja

incidentom (od meseca do godinu dana), ukljuĉujući razmatranje sledećih
pitanja:

 Eventualno sudsko gonjenje: dokazi se ĉuvaju sve dok se sudski

proces ne završi;
 Zadržavanje podataka: 180 dana npr. e-pošte, do 3 godine evidencije
o incidentima;
 Troškovi: ĉuvanje originalnog hardvera i medija kompromitovanog
sistema kao dokaza o incidentu, koji se uvećavaju sa porastom broja
incidenata.

U PRILOGU III 7I u Tabeli 3.5 prikazana je kontrolna lista koja

obezbeĊuje glavne korake inicijalnog rukovanja sa incidentom. Po
završetku analize treba koristiti kontrolnu listu iz Tabele 3.6, koja

- 576 -
ukazuje na kategoriju incidenta. Ova lista je generiĉka i odnosi se na
incidente koji ne pripadaju striktno ni jednoj kategoriji. Kontrolne liste su
samo uputstvo za analitiĉara koje treba slediti u izvršavanju glavnih
koraka, a ne precizne procedure. U PRILOGU III 7J preporuĉena je
generiĉka procedura za upravljanje incidentom [7].

Kapaciteti za upravljanje kompjuterskim incidentom nalaze se u

odreĊenoj meĊuzavisnosti sa brojnim servisima zaštite: planiranje
vanrednih dogaĊaja; obuka o zaštiti; upravljanje rizikom i personalna
zaštita.

U procesu upravljanja kompjuterskim incidentom, jedna od brojnih

kritiĉnih taĉaka je odreĊivanje prioriteta reagovanja na incidente. Vežba
GIII P7A razvijena je sa ciljem da se poboljša percepcija administratora i
specijalista zaštite u procesu identifikovanja karaktera incidenta i
odreĊivanja prioriteta reagovanja.

- 577 -
3. REZIME

Kompjuterski dogaĊaj je bilo koje uoĉljivo dešavanje u sistemu ili

mreţi. Pod incidentom se podrazumeva povreda ili imanentna pretnja za
povredu politike zaštite i povredu e primene politike i standarda prakse
zaštite. MeĊu brojnim podelama incidenata, uobiĉajena je kategorizacija
na bazi primarnih kategorija napada: odbijanje izvršavanja servisa (DoS),
maliciozni kôdovi, neovlašćeni pristup i nepropisno korišćenje.

Generalno, većina servisa na koje se organizacija oslanja leţi izvan njene

potpune kontrole, ali postoji mnogo naĉina da organizacija redukuje
uticaj ili ublaţi posledice dogaĊaja, preduzimanjem preventivnih mera
spreĉavanja posledica dogaĊaja. Kapaciteti za upravljanje incidentom
obuhvataju dve kljuĉne komponente: organizaciju kapaciteta i
upravljanje specifiĉnim tipovima incidenata.

Prema strukturi interventni tim za upravljanje incidentom moţe biti:

centralni, distribuirani i koordinirani tim. Popuna interventnog tima
moţe biti sa zaposlenim, zaposlenim i spoljnim saradnicima i potpuno
iznajmljenim ĉlanovima tima. Primarni cilj razvoja kapaciteta za
upravljanje incidentom su saniranje štete i oporavak sistema, ali i za
preventivno spreĉavanja potencijalne štete, analizu rizika i obuku o
zaštiti.

Nagoveštaji incidenta mogu biti predznaci i indikatori. Predznak je neki

nagoveštaj da se neki incident moţe dogoditi u bliskoj budućnosti.
Indikator je znak da se neki incident vrlo verovatno dogodio, ili se
upravo dogaĊa. Predznaci i indikatori incidenta identifikuju se iz više
razliĉitih izvora, od kojih su najĉešći alarmi zaštite raĉunara, log
datoteke, javno raspoloţive informacije i ljudi.

Proces upravljanja kompjuterskim incidentom ima 4 kljuĉne faze:

priprema, detekcija i analiza, saniranje posledica i oporavak i analiza
iskustava.

Strategija saniranja posledica incidenta varira u zavisnosti od tipa

incidenta. Preporuĉljivo je da se razviju posebne strategije saniranja
posledica od glavnih kategorija incidenata i za sve glavne tipove
incidenata. Kriterijume za odreĊivanje odgovarajuće strategije saniranja
incidenta treba eksplicitno dokumentovati, da bi se lakše donosile odluke.

- 578 -
Ovi kriterijumi treba da ukljuĉuju: potencijalna oštećenja i kraĊu
objekata; obavezu ĉuvanja dokaza za forenziĉku analizu i veštaĉenje;
raspoloţivost servisa; vreme i resurse potrebni za implementaciju
strategije; efektivnost strategije; trajnost rešenja (hitno, privremeno,
trajno).

Detektori upada (IDS/IPS) u IKT sistem, osnovni alati za detekciju

povrede sistema zaštite, prikupljaju informacije o napadu i napadaĉu za
forenziĉku istragu i analizu. Dobro upravljanje upadom u IKT sistem,
preventiva je svih potencijalnih problema i omogućava pokretanje istraga
o incidentu. Detekcija i analiza incidenta uvek su predznaci ili indikatori
pojave incidenta, ako im se moţe verovati, što naţalost nije uvek sluĉaj,
zbog velikog broja laţnih pozitivnih alarma, ili netaĉnih indikacija. Da bi
se prevazišle teškoće u toku analize incidenata treba sprovoditi proceduru
najbolje prakse.

Analiza iskustava iz upravljanja incidentima, iako najvaţnija, ĉesto se

najĉešće zanemaruje. U toku analize iskustava treba razmatrati brojna
pitanja: šta se taĉno desilo i u koje vreme, kako su se ponašali
menadţment i zaposleni, da li je sprovedena dokumentovana procedura,
da li je procedura adekvatna, koje su informacije bile potrebne
neposredno po izbijanju incidenta, da li su preduzete neke akcije koje
mogu spreĉiti oporavak, šta bi zaposleni i menadţment sledeći put uradili
drugaĉije sa sliĉnim incidentom, koje korektivne akcije mogu spreĉiti
sliĉne incidente u budućnosti, koji su dodatni alati i resursi potrebni da se
detektuju, analiziraju i saniraju budući incidenti?

Kapaciteti za upravljanje kompjuterskim incidentom nalaze se u

odreĊenoj meĊuzavisnosti sa sledećim servisima zaštite: planiranje
vanrednih dogaĊaja, operativna podrška, obuka u zaštiti i stvaranje svesti
o potrebi zaštite, upravljanje bezbednosnim rizikom, personalna zaštita i
edukacija i obuka.

- 579 -
4. KLJUĈNI TERMINI

Detektor upada u sistem (IDS): Softverski alat koji traţi sumnjive

aktivnosti i alarmira administratora.
Distribuiran DoS (DDoS): Neka DoS tehnika koja koristi brojne
hostove za izvršavanje napada.
DogaĊaj: Svako uoĉljivo dogaĊanje u mreţi ili sistemu.
Forenzika raĉunara: Praksa skupljanja, akvizicije, ĉuvanja i analize
kompjuterskih digitalnih dokaza za potrebe forenziĉke istrage, na naĉin
koji odrţava integritet podataka.
Incident: povreda ili imanentna pretnja bezbednosnim politikama
raĉunara, primeni usvojenih politika ili standarda prakse zaštite.
Interventni tim: Ljudski kapaciteti uspostavljeni radi pomoći za
odgovore na bezbednosne kompjuterske incidente (CIRT – Computer
Incident Response Team, CERT- Computer Emergancy Response Team,
CIRC - Computer Incident Response Center).
Kapaciteti za upravljanje incidentom: Ukupni kapaciteti uspostavljeni
radi pomoći za odgovore na bezbednosne kompjuterske incidente
Kombinovani incident: Jedinstven incident koji obuhvata dva ili više
incidenta.
Laţni pozitiv: Neki alarm koji nekorektno indicira da se dogaĊa
maliciozna aktivnost.
Maliciozni kod: Virus, crv, Trojanac ili drugi entitet na bazi
programskog koda koji inficira host.
Nagoveštaj: znak da se neki incident moţe dogoditi ili se dogaĊa.
Neovlašćen pristup: Neki korisnik dobije logiĉki ili fiziĉki pristup
mreţi, sistemu, aplikaciji, podatku ili drugom objektu IKT sistema, bez
ovlašćenje.
Nepropisno korišćenje: Lice koje povredi prihvatljivu politiku
korišćenja raĉunarskog sistema.
Odbijanje izvršavanja servisa (DoS): Neki napad koji spreĉava ili
ometa ovlašćeno korišćenje mreţa, sistema ili aplikacija iscrpljivanjem
resursa.
Odgovor na incident: Videti ―Upravljanje incidentom.‖
Operacija bekapovanja (Backup Operacion) – metod operacija za
izvršavanje bitnih zadataka (kao što je analiza rizika) posle prekida rada
IKT sistema i nastavljanja rada dok se objekti sistema ne oporave u
dovoljnoj meri.
Oporavak (Recovery) – restauracija objekata IKT sistema i druge
odnosne infrastrukture posle fiziĉkog uništenja ili glavnog oštećenja.

- 580 -
Oporavak od katastrofe (Disaster Recovery) – proces ponovne
izgradnje operativnih funkcija i infrastrukture po završetku
katastrofalnog dogaĊaja.
Predznak: Neki nagoveštaj da se napadaĉ moţda priprema da izazove
incident.
Tehniĉke aktivnosti: u IKT odnosi se generalno na bezbednosne
incidente koji bez struĉno-tehniĉkog odgovora mogu naneti ozbiljne štete
u sistemu.
Upravljanje bezbednosnim zakrpama: Proces akvizicije, testiranja i
distribucije bezbednosnih zakrpa odgovarajućim administratorima i
korisnicima u celoj organizaciji.
Upravljanje incidentom: Smanjenje povreda politika zaštite i
preporuĉene najbolje prakse zaštite.

- 581 -
5. LITERATURA:

1. Computer Security Incident Response Team (CSIRT), Frequently

Asked Questions (FAQ),
http://www..cert.org/csirts/csirt_faq.html, 2006.
2. http://www..cert.org, 2006.
3. Kossakowski K., DFN CERT: Bibliography of Computer Security
Incident Handling Documents,
http://www.cert.dfn.de/eng/pre99papers/certbib.html, avgust
2003.
4. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
5. NIST SP 800-12, An Introduction to Computer Security: The
NIST Handbook, , http://www.nist.gov/publications, verzija 2004.
6. NIST SP 800-3, "Establishing a Computer Incident Response
Capability", http://www.nist.gov/publications, 1999.
7. NIST SP 800-61, Computer Security Incident Handling Guide,
http://csrc.nist.gov/publications/nistpubs/index.html, 2004. 3
8. Purser S., A practical Guide to Managing Information Security,
Artech House, Boston-London, www.artechhouse.com, 2004.
9. Russell L. Brand, Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery,
brand@lll-crg.llnl.gov, 1990.
10. US Department of Homeland Security, Federal Computer
Incident Response Center: Incident Handling Checklists,
http://www.fedcirc.gov/incidentResponse/IHchecklists.html,
2003.
11. USA CERT, www.uscert.org, 2005.

- 582 -
8. UPRAVLJANJE VANREDNIM DOGAĐAJEM

0. UVOD

Kada završite ovo poglavlje razumećete značaj:

- planiranja vanrednih događaja (VD) u IKT sistemu

- procesa upravljanja VD
- izbora strategije za upravljanje VD
- pripreme rezervne lokacije i IKT kapaciteta
- izbora kapaciteta za oporavak IKT sistema od VD
- uvežbavanja plana VD do rutinskog izvršavanja

Planiranje vanrednih dogaĊaja ukljuĉuje više od samog planiranja

evakuacije izvan zone u kojoj je uništen IKT centar organizacije ili drugi
kapaciteti IKT sistema organizacije. Plan obuhvata i kako neka
organizacija odrţava kritiĉne IKT funkcije u operativnom stanju u
sluĉaju većih i manjih prekida i nastavlja poslovanje u vanrednim
okolnostima. U većini kriznih situacija za tipiĉne poslovne IKT sisteme,
potrebno je uspostaviti lanac upravljanja u i obezbediti svest
menadţmenta o potrebi izgradnje kapaciteta organizacije za efikasno
reagovanje. Ovo je bitno i zbog mogućnosti da kritiĉni pojedinci ne budu
na raspolaganju u datom trenutku, ili ne bude moguće preduzeti
neophodne akcije u ograniĉenom periodu vremena. U kategoriju
vanrednih dogaĊaja u IKT sistemu mogu se svrstati: sve prirodne
katastrofe i nesreće, poţari, poplave, nestanak elektriĉnog napajanja,
štrajkovi i odsustvo zaposlenih sa posla, kvarovi sistema za
grejanje/hlaĊenje, opšti kvarovi opreme i dr. Ovi su dogaĊaji stohastiĉki
po svojoj prirodi i štetne posledice njihovog uticaja mogu se smanjiti
samo planiranjem i uveţbavanjem scenarija vanrednih dogaĊaja i
oporavka sistema.

Za uspostavljanje kapaciteta organizacije za upravljanje vanrednim

dogaĊajem treba definisati i implementirati proces planiranja vanrednih
dogaĊaja, ukljuĉujući postavljanje što realnijih scenarija i uveţbavanje
svih delova organizacije i IKT sistema.

- 583 -
1. PROCES UPRAVLJANJA VANREDNIM DOGAĐAJEM

1.1. Proces planiranja vanrednih dogaĊaja

Planiranje vanrednog dogaĊaja i nastavljanja poslovanja najsloţeniji

je deo posla. Kada organizacija odluĉi kako će nastavi poslovanje,
primena plana je tada relativno lak zadatak. Proces planiranja vanrednih
dogaĊaja odvija se u šest faza, [7]:

a. identifikovanje funkcija IKT sistema kritičnih za misiju

organizacije;
b. identifikovanje resursa koji podržavaju kritične IKT funkcije;
c. procena potencijalnih vanrednih dogaĎaja ili nesreća;
d. izbor strategije planiranja vanrednih dogaĎaja u IKT sistemu;
e. implementiranje strategije za upravljanja vanrednim dogaĎajima
i
f. testiranje i revizija strategije upravljanja vanrednim dogaĎajima
u IKT sistemu.

a. Identifikovanje IKT funkcija kritičnih za misiju organizacije osnovni

je preduslov za planiranje kontinuiteta poslovanja organizacije.
Definicija kritiĉne misije ili poslova IKT organizacije obiĉno se nalazi u
planu zaštite IKT sistema. Kriterijumi za odreĊivanje kritiĉnosti
misije/poslova IKT sistema mogu biti bazirani na vremenu oporavka
sistema, akumuliranom uticaju ili kombinaciji ova dva faktora. Posebno
je vaţno identifikovati i proceniti promene koje vanredni dogaĊaj moţe
izazvati, u vanradno vreme. Za većinu poslovnih funkcija IKT sistema
dostiţe se taĉka u kojoj uticaj vanrednih dogaĊaja postaje toliko velik da
su bespredmetni pokušaji odrţavanja kontinuiteta funkcija IKT sistema.
Oĉigledno, kritiĉne funkcije IKT sistema treba oporaviti pre nego što se
ova taĉka dostigne. U celom procesu upravljanja vanrednim dogaĊajima
u IKT sistemu vreme je kritiĉan faktor i veoma je vaţno što je moguće
ranije poĉeti sa identifikacijom implikacija vremena na proces, kao i
odreĊivanje prioriteta saniranja posledica. Potpuna redundantnost za
svaku kritiĉnu funkciju veoma je skupa za većinu organizacija. U sluĉaju
katastrofe, odreĊene IKT funkcije neće se izvršiti. Ako se odrede i
odobre odgovarajući prioriteti, to moţe povećati sposobnost organizacije
da preţivi vanredni dogaĊaj, [14].

- 584 -
b. Identifikovanje resursa koji podržavaju kritične IKT funkcije i
vremenska ograniĉenja ovih funkcija, tj. da li je resurs potreban stalno ili
samo u nekom periodu i efekat neraspoloţivosti resursa na misiju ili
funkcije IKT sistema sledeći je korak u planiranju vanrednog dogaĊaja.
Osnovni problem je što razliĉiti menadţeri vide i identifikuju razliĉite
IKT resurse, ili previĊaju interakciju resursa koji podrţavaju kritiĉne
funkcije, od kojih nisu svi IKT resursi: ljudi, IKT kapaciteti za
procesiranje, servisi IKT sistema, podaci i aplikacije, fizička
infrastruktura i dokumentacija IKT, [5].

Planiranje vanrednih dogaĊaja u IKT sistemu treba da obuhvati sve

resurse koji su neophodni da se funkcija izvrši, bez obzira da li se
direktno odnose na IKT sisteme. Kada se dogodi prekid rada u
organizaciji neki uticaj se ispolji odmah i veoma je skupo spreĉiti ga, ako
ne i nemoguće. MeĊutim, veći broj uticaja dogaĊa se posle izvesnog
vremena. Neki od ovih uticaja mogu se odloţiti preduzimanjem
odgovarajućih akcija, neki sasvim otkloniti, a neki se ne mogu spreĉiti.
Definisanje neophodnih resursa za suzbijanje posledica vanrednih
dogaĊaja treba da vrše ona lica koja znaju kako se IKT funkcije
izvršavaju i kako IKT objekti zavise od drugih resursa, kao i druge
kritiĉne zavisnosti, pošto svi resursi sistema i organizacije nisu kritiĉni za
izvršavanje najbitnijih funkcija.

Ĉesto je neophodno formirati tim za planiranje vanrednih dogaĊaja, da bi

se odredili potrebni resursi iz svake od 6 kategorija resursa i da bi se
razumelo kako resursi podrţavaju kritiĉne funkcije IKT sistema. Tipiĉan
tim sadrţi predstavnike iz razliĉitih organizacionih jedinica organizacije,
a timom najĉešće rukovodi koordinator za upravljanje vanrednim
dogaĊajima, koga imenuje rukovodstvo organizacije. Tim ima
predstavnike iz najmanje tri sledeće grupe zaposlenih: poslovnog sistema,
upravne strukture organizacije i rukovodstva IKT sistema, a drugi
predstavnici organizacije pozivaju se po potrebi, [5].

Ljudski resursi su najvaţniji resursi svake organizacije. U IKT oblasti

ljudski resursi obuhvataju administratore, specijaliste zaštite, operatere
(tehniĉari ili programeri) i korisnike (sluţbenici za unos podataka, ili
analitiĉari informacija i dr.).

IKT kapaciteti za procesiranje tradicionalno su prioritetni za planiranje

vanrednih dogaĊaja u IKT sistemima. Iako bekapovanje IKT servisa

- 585 -
ostaje glavna aktivnost, vaţna su i alternativna rešenja, jer kritiĉne
zadatke mogu izvršavati lokalne mreţe, mini kompjuteri, radne stanice,
PC u svim formama centralizovanog i distribuiranog IKT procesiranja

IKT sistemi izvršavaju automatizovane aplikacije koje procesiraju

podatke. Ako se IKT procesiranje izvršava na alternativnom (bekap)
hardveru, aplikacija mora biti kompatibilna sa alternativnim hardverom,
OS, drugim programima (ukljuĉujući verziju i konfiguraciju) i drugim
tehniĉkim faktorima. Potrebno je periodiĉno verifikovati IKT
kompatibilnost na primarnoj i rezervnim lokacijama.

Servisi IKT sistema koriste se za izvršavanje brojnih funkcija

organizacije. Najvaţniji su komunikacioni i informacioni servisi.
Komunikacioni servisi mogu biti za prenos podataka i glasa, ali se u
većini organizacija upravljaju istim servisima. Informacioni servisi
ukljuĉuju svaki izvor informacija izvan organizacije, ukljuĉujući on-line
servise e-Uprave, privatne baze podataka, novinske servise i elektronske
biltene.

Fizička IKT infrastruktura, bezbedno radno okruţenje, odgovarajuća

oprema i alati neophodni su za efektivan rad zaposlenih. IKT sistemi
zahtevaju bezbedan radni prostor i servise, kao što su napajanje
elektriĉnom energijom, grejanje i hlaĊenje, a podaci i elektronski mediji
zahtevaju fiziĉki prostor za skladištenje.

Dokumentacija, elektronske evidencije ili obrasci, koji podrţavaju većinu

funkcija IKT sistema, mogu biti znaĉajni i za legalne potrebe istrage
kompjuterskog kriminala. U organizaciji gde su elektronska dokumenta
referentna forma, mora se obezbediti i neprekidno kontrolisati pristup tim
dokumentima.

Plan mera za vanredne dogaĊaje treba da obuhvati svaki od napred

opisanih resursa.

c. Identifikovanje potencijalnih vanrednih dogaĎaja u IKT sistemu i

njihovih posledica prethodi razvoju scenarija šireg spektra potencijalnih
vanrednih dogaĊaja, koji mogu ugroziti IKT sistem. Scenario treba da
ukljuĉi male i velike vanredne dogaĊaje. Tipiĉan scenario vanrednih
dogaĊaja treba da obuhvati odgovore na pitanja o svim resursima, [2],
[5]:

- 586 -
Ljudski resursi: Mogu li zaposleni doći na posao? Da li je kritiĉno
osoblje voljno da proĊe prekine štrajk? Koji zaposleni ima kritiĉna
znanja i veštine? Mogu li se zaposleni lako evakuisati na rezervnu
lokaciju?
Kapacitet procesiranja: Da li je IKT sistem ugroţen? Šta se dogaĊa ako
neki od sistema (ali ne i svi) nije u operativnoj upotrebi? Da li je
saĉinjena lista prioritetnih akcija? Koje su komunikacione veze na
raspolaganju?
IKT aplikacije i podaci: Da li je ugroţen integritet podataka? Da li je
neka IKT aplikacija sabotirana? Da li neka aplikacija moţe raditi na
drugoj procesorskoj platformi?
IKT servisi: Da li IKT sistem moţe komunicirati sa drugima? Sa kojim
sistemima IKT sistem moţe komunicirati? Mogu li ljudi komunicirati?
Da li su IKT servisi u prekidu? Koliko dugo su IKT servisi u prekidu? Da
li se mogu koristiti usluge iznajmljenih udaljenih transakcija?
Infrastruktura: Imaju li zaposleni mesta za rad (sto, stolica)? Da li imaju
alate i opremu za svoje poslove? Da li zaposleni mogu zaposesti zgradu u
kojoj treba da rade? Da li postoji funkcionalna infrastruktura radnog
okruţenja (voda, kanalizacija, grejanje, hlaĊenje)?
Dokumentacija: Da li potrebne elektronska dokumenta mogu biti
pronaĊena? Da li su elektronska dokumenta ĉitljiva?

Razvoj višestrukog scenarija pomaţe u razumevanju vrste i obima

vanrednih dogaĊaja koje plan treba da obuhvati. Vaţno je ne upasti u
zamku razvoja strategije odbrane i planova za svaki pojedinaĉni scenario.

d. Izbor strategije za planiranje upravljanja vanrednim dogaĎajem je

sledeći korak za planiranje oporavka kritiĉnih objekata IKT sistema i
drugih resursa. U evaluaciji alternativa, neophodno je razmotriti koje su
mere zaštite instalirane da spreĉe i minimiziraju uticaje vanrednih
dogaĊaja u IKT sistemu. Pošto ni jedan skup mera i metoda zaštite ne
moţe rentabilno spreĉiti sve potencijalne vanredne dogaĊaje u IKT
sistemima, potrebno je koordinirati preventivne mere i aktivnosti za
oporavak sistema.

- 587 -
 Strategija planiranja vanrednih dogaĊaja u IKT sistemima normalno
sadrţi tri dela [1]:

1. Hitne intervencije - inicijalne akcije za zaštitu ljudskih ţivota i

smanjenja štete;
2. Oporavak sistema - akcije za obezbeĊivanje kontinuiteta kritiĉnih
funkcija sistema i
3. Nastavljanje rada - povratak IKT sistema u normalni rad.

Odnos izmeĊu oporavka i nastavljanja rada sistema je veoma vaţan. Što

je duţe potrebno da se nastavi normalni rad sistema, to će duţe
organizacija morati da radi u modu oporavljenog sistema. Oporavak
sistema nije cilj sam po sebi, a nastavak normalnog rada sistema,
ukljuĉujući povratak u rekonstruisanu ili novu lokaciju, uvek se mora
dogoditi. Povratak i premeštanje operacija IKT sistema uvek izazivaju
neke prekide. Faza povratka u normalni rad treba da bude ukljuĉena u
sveobuhvatni plan za vanredni dogaĊaj.

Neke organizacije strategiju i proces upravljanja vanrednim dogaĊajem

dele na hitne intervencije, operacije bekapovanja i oporavak sistem, što
nije presudno za uspešno upravljanje vanrednim dogaĊajem. Ipak,
osnovne funkcije navedenih faza procesa treba da sadrţi svaki ozbiljniji
plan za upravljanje vanrednim dogaĊajem [1].

Izbor strategije zasniva se na praktiĉnoj analizi IKT sistema, ukljuĉujući

izvodljivost i troškove. Za donošenje odluke optimalnoj strategiji treba
analizirati svaku od kategorija IKT resursa, opcije oporavka, rentabiliteta
ili rizika. Analiza treba da ima teţište na onim oblastima gde nije jasno
koja je strategija za upravljanje vanrednim dogaĊajem i oporavak IKT
sistema najbolja. Sledeći primeri ilustruju razvoj strategije za
upravljanje nekim vanrednim dogaĊajima.

Primer 1: Ako administrator IKT sistema za LAN mora biti odsutan

duţe vreme, zbog bolesti ili nesreće, treba napraviti ugovor za rad na
odreĊeno vreme sa drugim administratorom za obavljanje ovih poslova.
Zato stalni administrator mora neprekidno odrţavati dokumentaciju
aţurnom, tako da poslove administracije LANa moţe preuzeti drugi
administrator bez većih problema. Ova strategija nije skupa, ali treba
oĉekivati da je nivo servisa manji u oba LANa, što moţe naterati
menadţera da odustanu od takvog ugovora.

- 588 -
Primer 2: IKT organizacija zavisi od on-line servisa koje obezbeĊuje
komercijalni provajder usluga. IKT organizacija nije više sposobna da
prima manuelno informacije (npr. iz referentnog uputstva vendora) u
prihvatljivom vremenu, a nema drugih komparativnih servisa. U ovom
sluĉaju, IKT organizacija se oslanja na plan za vanredne dogaĊaje
provajdera usluga. IKT organizacija plaća provajderu premiju za
dobijanje prioritetnih servisa u sluĉaju da provajder usluga mora raditi sa
redukovanim kapacitetima.
Primer 3: Veliki IKT centar za obradu podataka ima ugovor sa
proizvoĊaĉem softvera za glavnu lokaciju i sa telekomunikacionim
provajderom za komunikacione vodova na glavnoj lokaciji i planove da
premesti zaposlene, komunikacione linije, uskladišti aţurne kopije
podataka i IKT aplikacija i potrebnu papirnu dokumentaciju na rezervnoj
lokaciji. Ovakav plan za vanredne dogaĊaje je priliĉno skup, ali moţe biti
potpuno opravdan.
Primer 4: Jedna IKT organizacija ima distribuirano procesiranje na dve
glavne lokacije, na kojima se nalaze mali i srednji kapaciteti za
procesiranje (PC i mikroraĉunari). Ako se jedna lokacija izgubi, druga
moţe preuzeti kritiĉne funkcije dok se ne nabavi više IKT opreme (vrsta
uzajamnog bekapovanja - mutual backup). Rutiranje prenosa glasa i
podataka moţe se izvršiti transparentno. Bekapovane kopije jedne
lokacije mogu biti uskladištene na drugoj lokaciji i obrnuto. Ovaj plan
zahteva striktnu kontrolu kompatibilnosti aplikacija razvijenih na obe
lokacije, kao i jedinstvenu obuku za izvršavanje svih funkcija IKT
sistema.

Ljudski resursi. U katastrofalnom vanrednom dogaĊaju, ljudi mogu biti

pod znaĉajnim stresom ili u panici. Ako je dogaĊaj u IKT sistemu
nesreća regionalnog karaktera, zaposleni prvo brinu za porodice i
imovinu. Neki zaposleni ne mogu, a neki neće hteti da doĊu na posao, što
znaĉi da treba privremeno zaposliti nova lica. Ovo moţe uvesti
bezbednosnu ranjivost, jer po pravilu glavni prekid rada IKT sistema
uvek prati znaĉajna promena personala po uspostavljanju normalnog
reţima rada, što treba ukljuĉiti u plan za vanredne dogaĊaje. Plan za
vanredne dogaĊaje, posebno u fazi hitnih intervencija, teţište aktivnosti
normalno ima na spreĉavanju gubitka ljudskih ţivota.

- 589 -
Kapaciteti za procesiranje IKT sistema normalno se grupišu u šest
osnovnih kategorija, [12]:

1. Glavna (primarna) lokacija: postojeća zgrada opremljena sa IKT

kapacitetima;
2. Hladna lokacija: prazna rezervna zgrada sa osnovnom
infrastrukturom za smeštaj IKT opreme, koja se lako moţe
adaptirati u sluĉaju vanrednog dogaĊaja;
3. Vruća lokacija: zgrada na rezervnoj lokaciji opremljena sa
hardverom, softverom i mreţnom instalacijom, kompatibilnom
primarnoj mreţnoj instalaciji IKT sistema;
4. Redundantna lokacija: miror lokacija opremljena i konfigurisana
potpuno jednako kao primarna IKT lokacija;
5. Uzajamno bekapovanje: reciproĉni ugovori dopuštaju IKT
organizacijama da se meĊusobno pomognu u sluĉaju vanrednog
dogaĊaja. Osnovni problemi su potreba za ĉesto aţuriranje
sporazuma i planova i odrţavanje kompatibilnosti konfiguracija
IKT sistema i aplikacija;
6. Udaljena (online) iznajmljena transakcija: iznajmljena
organizacija po ugovoru vrši online transmisiju podataka radi
periodiĉnog bekapovanja sistema (normalno nekoliko ĉasova) da
bi se smanjili gubici podataka i vreme oporavka i
7. Hibridni sistemi: bilo koja kombinacija gornjih kategorija.

Oporavak sistema treba izvršavati prema redosledu zahteva za

raspoloţivost IKT kapaciteta za procesiranje. Plan za oporavak sistema
treba da ukljuĉuje ugovore za zamenu opreme. Osnovni aksiom oporavka
IKT sistema od vanrednog dogaĊaja je bekapovanje (skladištenje
rezervnih kopija) podataka, programa i aplikacija izvan primarne lokacije
i korišćenje istih iz neke od rezervnih lokacija. Na Sl.1.1. prikazan je
dijagram rasta troškova bekapovanja i vremena oporavka IKT sistema u
funkciji strategije bekapovanja i vrste rezervne lokacije. Oĉigledno je da
troškovi bekapovanja rastu ako se ţeli smanjiti vreme oporavka sistema,
[3], [15].

- 590 -
 Troškovi
Rundantna
lokacija
(miror)

Udaljena
transakcija

Vruća
lokacija

Uzajamno
bekapovanje

Hladna
lokacija

Vreme oporavka

Sl.1.1. Dijagram troškova bekapovanja i vremena oporavka u

funkciji rezervne lokacije

Za aplikacije i podatke primarna strategija planiranja vanrednih je

regularno bekapovanje i skladištenje na alternativnu lokaciju. Vaţno je
odrediti koliko ĉesto se vrši bekapovanje i skladišti na alternativnoj
lokaciji i kako se transportuju na alternativnu lokaciju za procesiranje ili
nastavak normalnog rada sistema. Treba pratiti ažurnost- starost i
upotrebnu vrednost za korisnike i neusklaĎenost podataka. Potreba za
zaštitom IKT sistema ne nestaje kada IKT sistem neke organizacije radi u
vanrednim situacijama. U nekim sluĉajevima postoji potreba i za većom
zaštitom, na primer, zbog deljenja IKT resursa, koncentracije više resursa
u manji prostor, lili korišćenja zaposlenih po ugovoru, koji nisu dovoljno
bezbednosno provereni. U fazi oporavka sistema, inicijalno oporavljeni
podaci biće zastareli za vreme od poslednjeg bekapovanja do pojave
incidenta i vremena kada se sistem oporavlja. Ako su ovi podaci suviše
stari i nekorisni moraju se aţurirati, odnosno ĉešće bekapovati.

Da bi oporavljeni IKT sistem funkcionisao, bitne su usklaĊenost i

aţurnost bekapovanih podataka i sinhronizacija bekapovanih datoteka
uzetih sa razliĉitih delova IKT sistema u razliĉitim vremenima. U
protivnom mogu nastati problemi i sa restartovanjem IKT sistema sa
poznatim stanjem. Strategija bekapovanja IKT sistema treba da obezbedi
oporavak sistema na najefikasniji naĉin. Bekapovanje podataka, datoteka
i aplikacija kritiĉan je deo svakog plana za vanredne dogaĊaje, [5].

- 591 -
IKT servise za vanredne dogaĊaje moţe ponuditi provajder usluga.
Telekomunikacioni provajder usluga moţe prerutirati telekomunikacione
linije na novu lokaciju, a ISP takoĊe moţe preusmeriti saobraćaj na tu
lokaciju. Primarna lokacija je uobiĉajeno opremljena da prima
multimedijalne sadrţaje (podaci, ton, slika, video). Ako je jedan ISP
izbaĉen iz rada postoji mogućnost korišćenja drugog. Znaĉajno je
identifikovati koji je tip izgubljene komunikacije i da li je u pitanju
lokalna ili udaljena veza. Lokalne telefonska veza moţe se prebaciti na
mobilnu telefoniju, ali je znatno teţe prebaciti prenos velike koliĉine
podataka sa ţiĉne na beţiĉnu infrastrukturu. Pored toga, nastavak
normalnog rada sistema moţe zahtevati ponovno preusmeravanje
komunikacionih servisa.

IKT sistema sa visokom raspoloživosti i otpornosti na otkaze. Mehanizmi

visoke raspoloţivosti na otkaze predstavljaju korisnu meru koju
organizacija moţe preduzeti za nastavljanje poslovanja u sluĉaju
vanrednog dogaĊaja. Primer tehnologije za visoku raspoloţivost
podataka su RAID (Redundant Array of Independent Discs) ĉvrsti
diskovi, koji omogućavaju nastavak rada servera u sluĉaju kvara jednog
diska bez gubitaka podataka. Druga tehnologija je klaster servera koji
deli klijentsko opterećenje i još bolje toleriše otkaze od RAID sistema.
Ako otkaţe jedan server, drugi preuzima i nastavlja rad. Naravno ovi
sistemi su od male koristi ako su smešteni na istoj lokaciji. Miror servere
treba razmestiti na alternativne lokacije i povezati u širu regionalnu
mreţu (WAN). Raspoloţivost podataka obezbeĊuju i izvori neprekidnog
napajanja (UPS) u sluĉaju prekida napajanja elektriĉnom energijom, u
vremenu koje zavisi od kapaciteta sistema baterija UPS-a.

Redundantna fizička IKT infrastruktura, kao što su rezervni radni

prostor, servisi zaštite, nameštaj i druge potrebe za sluĉaj vanrednog
dogaĊaja u IKT sistemu, treba se planirati i ugovoriti, iako primarna i
rezervne lokacije moraju obezbediti i radni prostor zaposlenih, pored
smeštaja IKT opreme. Za premeštanje na rezervnu lokaciju, treba izraditi
procedure za evakuaciju i povratak na primarnu ili novu lokaciju. Zaštita
fiziĉke infrastrukture normalni je deo plana za hitne intervencije, kao što
je zaštita IKT opreme od vode iz PPZ sistema.

Dokumentacija, elektronska i papirna ukljuĉujući i arhiviranu papirnu, u

primarnoj strategiji upravljanja vanrednim dogaĊajem obiĉno se bekapuje
na magnetske medije, optiĉke diskove, mikrofilmove, mikrofiševe i

- 592 -
druge medije i uskladišti na rezervnoj lokaciji. Formulare, arhiviranu
papirnu dokumentaciju i druge potrebne papire treba uskladištiti na
pristupaĉnoj alternativnoj lokaciji.

Kada se izabere strategija za upravljanje vanrednim dogaĊajem u IKT

sistemu, potrebno je izvršiti odgovarajuće pripreme, dokumentovati
strategiju i obuĉiti zaposlene. Većina od ovih zadataka zahtevaju trajne
aktivnosti. U cilju razumevanja znaĉaja bekapovanja za proces planiranja
vanrednih dogaĊaja razvijena je Vežba GIII 8A.

e. Implementacija strategije za upravljanje vanrednim dogaĎajem u

IKT sistemu zahteva velike pripreme: uspostavljanje procedura za
bekapovanje podataka, datoteka i aplikacija; sklapanje ugovora i
sporazuma ako strategija zahteva; obnavljanje postojećih ugovora za
servise, zbog dodavanja novih servisa; nabavka IKT opreme, posebno za
redundantne kapacitete; aţurirati servise i opremu za bekapovanje i
redundantne kapacitete, pa i ugovore i sporazume; izvršiti redovnu
zamenu dotrajale ili zastarele IKT opreme; formalno imenovati
odgovorna lica za izvršavanje zadataka u sluĉaju vanrednog dogaĊaja; po
potrebi povećati nivo odgovornosti lica za kontrolu i upravljanje
vanrednim dogaĊajem i dr. Svi ovi aspekti i ograniĉenja treba da budu
dokumentovani. Vaţno je odrţavati pripreme aţurnim, ukljuĉujući i
dokumentaciju. Lica izabrana za izvršavanje zadataka u sluĉaju
vanrednog dogaĊaja ĉine tim za planiranje i upravljanje vanrednim
dogaĊajem. Za implementaciju je najznaĉajnije:

- koliko scenarija i verzija plana treba razviti i

- ko priprema svaku verziju plana pojedinaĉno?

Oba pitanja treba da kruţe u celoj organizaciji tokom implementacije

strategije upravljanja vanrednim dogaĊajem. Izabranu strategiju i naĉin
implementacije treba dokumentovati u politici i procedurama zaštite
organizacije. Za male i manje kompleksne IKT sisteme, plan za vanredne
dogaĊaje moţe biti deo plana zaštite IKT sistema. Za velike i
kompleksne IKT sisteme, plan zaštite moţe da sadrţi kratak pregled
plana za upravljanje vanrednim dogaĊajem, koji moţe biti poseban
dokument.

- 593 -
Neke organizacije imaju samo jedan plan za celu organizaciju, a druge za
svaki razliĉiti IKT sistem, aplikaciju i druge resurse, ili posebne planove
za svaku kritiĉnu misiju ili poslovnu funkciju kritiĉnih resursa. Izbor
zavisi od konkretnih okolnosti za svaku organizaciju. Sa više planova
kritiĉni su koordinacija i tendencija dupliranje ili preklapanje aktivnosti,
što je neefikasno i skupo. U centralizovanom planiranju, najbolje je
odrediti koordinatora za upravljanje vanrednim dogaĊajem, koji priprema
plan sa ostalim funkcionalnim menadţerima.

Dokumentovan plan za vanredne mora biti aţurno odrţavan u skladu sa

promenama u IKT sistemu, okruţenju, normativnom okviru i uskladišten
na bezbedno mesto. Pisani dokument plana je kritiĉan faktor u toku
vanrednog dogaĊaja, posebno ako lice koje ga je izradilo nije na
raspolaganju. Zato plan mora biti napisan jasno sa jednostavnim jezikom
sa takvim opisom aktivnosti i zadataka koje treba izvršiti u sluĉaju
vanrednog dogaĊaja da i lice sa minimalnim poznavanjem stanja moţe
pristupiti realizaciji plana. Generalno, korisno je uskladištiti aţurne
kopije plana za vanredne dogaĊaje na nekoliko lokacija, ukljuĉujući sve
rezervne lokacije.

Obuka zaposlenih za vanredni dogaĎaj obavezna je za sve zaposlene.

Novi zaposleni moraju se obuĉiti po dolasku u organizaciju. Po potrebi
povremeno treba izvoditi veţbe na kojima zaposleni praktiĉno
uveţbavaju svoje uloge u sluĉaju vanrednog dogaĊaja. Najvaţnije su
simulacije prirodnih katastrofa i uveţbavanje ponašanja i postupaka
zaposlenih. Na veţbama se mogu testirati razliĉiti scenariji i komponente
IKT sistema. Odrţavanje plana za vanredne dogaĊaje mora se ugraditi u
procedure za upravljanje promenama u IKT sistemu tako da se dogradnja
sistema vrši po planu. Vaţna iskustva sa veţbi i ispitivanja opreme za
vanredne dogaĊaje treba iskoristiti za korekcije plana.

Obuka je posebno vaţna za efektivno reagovanje zaposlenih u toku hitnih

intervencija, koje treba izveţbati do automatizma. U sluĉaju nekih
vanrednih dogaĊaja, na primer, poţara, nema vremena da se konsultuju
uputstvo za rad i procedure. Zavisno od prirode dogaĊaja, moţe biti, ali
ne mora dovoljno vremena za zaštitu IKT opreme i drugih resursa.
Praksa i vrhunska uveţbanost potrebni su da bi se reagovalo efikasno i
efektivno, posebno u sluĉajevima kada je u pitanju spašavanje ljudskih
ţivota.

- 594 -
f. Ispitivanje (testiranje) i reviziju plana za vanredne dogaĊaje treba
vršiti periodiĉno i uveţbavati, pošto uvek ima neka slabost u planu koja
se pokaţe u toku implementacije i uveţbavanja. Plan vremenom
zastareva kako se menjaju resursi za izvršavanje kritiĉnih IKT funkcija,
pa se moraju specifiĉno dodeliti odgovornosti za odrţavanje aţurnosti
plana zaposlenim u organizaciji. Nivo i uĉestanost uveţbavanja i
testiranja plana za vanredne dogaĊaje variraju od organizacije do
organizacije i izmeĊu IKT sistema. Postoje nekoliko vrsta testiranja,
ukljuĉujući reviziju, analizu i simulaciju katastrofe.

Revizija moţe biti jednostavan test za proveru taĉnosti dokumentacije

plana za vanredne dogaĊaje i moţe se proveriti da li su: sva zaposleni na
spisku još uvek u organizaciji i imaju planirane odgovornosti; taĉni
telefoni u kući i na radnom mestu, podaci o organizaciji i zgradi,
brojevima soba i.t.d.; da li se datoteke mogu izvući iz sistema za
bekapovanje i da li zaposleni poznaju procedure za vanredne dogaĊaje.

Analiza se moţe izvršiti na celom planu ili delu plana, kao što su
procedure za hitne intervencije. Dobro je da analizu vrši lice koje nije
radilo u razvoju plana, ali ima dobro radno iskustvo i znanje za
obavljanje kritiĉnih funkcija i upotrebu resursa za podršku. Analitiĉari
slede strategiju plana, traţeći logiĉne ili procesne slabosti u planiranju i
intervjuišu funkcionalne menadţere, menadţere za resurse i druge
zaposlene, da bi nadomestili nedostajući ili zamenili nefunkcionalni delo
plana.

Simulacija krizne situacije katastrofe obezbeĊuje: validne informacije o

greškama u planu za vanredne dogaĊaje i za stvarnu situaciju;
uveţbavanje procedura za realnu kriznu situaciju i kritiĉne informacije
korisne za nastavljanje poslovanja. Iako simulacije i testiranja mogu biti
skupi, što je kritiĉnija funkcija za koju se simulira vanredni dogaĊaj, to je
simulacija rentabilnija. Simulacija vanrednog dogaĊaja moţe se izvršiti
koristeći rezervnu IKT opremu za oporavak sistema (tzv. vruće
testiranje), ili se moţe izvršiti na papiru (tzv. papirološki test), koji moţe
proveravati ljude i plan, ali ne i IKT opremu. Prednost vrućeg testiranja
je što se moţe smanjiti vreme, povećati broj funkcija koje treba testirati.

- 595 -
2. MEĐUZAVISNOSTI SA DRUGIM KONTROLAMA ZAŠTITE

Pošto sve mere i metode zaštite zajedno pomaţu da se spreĉe

vanredni dogaĊaji u IKT sistemu, praktiĉno postoje meĊuzavisnosti ove
komponente sa svim kontrolama zaštite, a najvaţnije su:
Analiza rizika: obezbeĊuje alat za analizu rentabilnosti kontrola zaštite u
razliĉitim opcijama planova za vanredne dogaĊaje, koristi se za
identifikovanje kritiĉnih IKT objekata i izbor komponenti zaštite za
spreĉavanje uticaja potencijalnih pretnji za ove IKT u pripremnoj fazi
procesa izrade plana.
Fizička zaštita IKT sistema i okruženja: preventivno pomaţe da se
spreĉe vanredni dogaĊaji u IKT sistemu od pretnji kao što su poţar,
nestanak napajanja, poplava zbog kvara vodovodnih instalacija ili
prirodnih katastrofa.
Upravljanje incidentom: smatra se potskupom vanrednih dogaĊaja koji
izazivaju tipiĉne pretnje za IKT sistem i mora se obuhvatiti u planu za
vanredne dogaĊaje.
Operativne kontrole: periodiĉno bekapovanje datoteka, servisa i
aplikacija, spreĉavanje incidenata i oporavak sistema od najĉešćih pretnji
kao što su kvar ĉvrstog diska (HD) ili korupcija datoteka (instaliranje
antivirusne zaštite na radnim stanicama), obavezne su operativne mera
zaštite u svakodnevnom radu, kao i u planu za vanredne dogaĊaje.
Politike zaštite: - neophodne su za izradu i dokumentovanje procesa
planiranja vanrednih dogaĊaja, eksplicitno dodeljuju odgovornosti svim
zaposlenim u procesu zaštite, a posebno u sluĉaju vanrednog dogaĊaja
(kompjuterskog incidenata).

Troškovi razvoja i implementacije plana za vanredne dogaĊaje u IKT

sistemu mogu biti znaĉajni, zavisno od izbora strategije.

U PRILOGU III 8A prikazan je generiĉki nacrt strukture plana za

vanredne dogaĊaje, [3], [5].

- 596 -
3. REZIME

Plan za vanredni dogaĊaj ukljuĉuje evakuaciju IKT kapaciteta

izvan ugroţene zone, naĉin odrţavanja kritiĉnih IKT funkcija u
operativnom stanju i oporavak sistema.

Proces planiranja vanrednih dogaĊaja odvija se u šest koraka (faza):

identifikovanje funkcija IKT sistema kritiĉnih za misiju/poslove
organizacije, identifikovanje objekata koji podrţavaju kritiĉne IKT
funkcije, procena potencijalnih vanrednih dogaĊaja, izbor strategije
upravljanja vanrednih dogaĊaja, implementacija strategije upravljanja
vanrednim dogaĊajima, testiranje i revizija strategije upravljanja
vanrednim dogaĊajima u IKT sistemu. Za većinu poslovnih funkcija IKT
sistema postoji taĉka u kojoj uticaj vanrednih dogaĊaja postaje toliki da
su bespredmetni pokušaji odrţavanja kontinuiteta rada sistema. Vreme je
kritiĉan faktor u celom procesu upravljanja vanrednim dogaĊajima i treba
što je moguće ranije poĉeti sa utvrĊivanjem uticaja vremena na proces,
kao i odreĊivanje prioriteta saniranja vanrednih dogaĊaja.

Posle identifikovanja kritiĉnih poslova/misije i funkcija, potrebno je

identifikovati resurse koji to podrţavaju, vremenski okvir u kojem se
svaki resurs koristi i efekat neraspoloţivosti resursa na misiju ili funkcije
IKT sistema. U identifikovanju IKT resursa, tradicionalan problem je da
razliĉiti menadţeri vide i identifikuju razliĉite resurse, ali previĊaju
njihovu interakciju u podršci misije/poslova IKT organizacije.

Razvoj scenarija potencijalnih vanrednih dogaĊaja pomaţe u razviju

plana i treba da obuhvati: ljudske resurse, kapacitete za procesiranja,
aplikacije i podatke, IKT servise, infrastrukturu i dokumentaciju.
Neophodno je razmotriti koje su mere zaštite instalirane da spreĉe i
smanje uticaj vanrednih dogaĊaja u IKT sistemu. Potrebno je koordinirati
preventivne mere i aktivnosti za oporavak sistema. Strategija planiranja i
upravljanja vanrednih dogaĊaja u IKT sistemima normalno sadrţi: hitne
intervencije, oporavak sistema i nastavak poslova.

Plan za upravljanje vanrednim dogaĊajima mora biti napisan, aţurno

odrţavan, u skladu sa svim promenama i uskladišten na bezbedno mesto.
Svi zaposleni treba da proĊu obuku za duţnosti u sluĉaju vanrednog
dogaĊaja. Za implementaciju strategije zaštite kritiĉnih IKT funkcija i
resursa za podršku treba mnogo priprema; izvršava je tim za planiranje i

- 597 -
upravljanje vanrednim dogaĊajem, a najznaĉajniji su broj scenarija i
verzija planova koje treba razviti i odgovorna lica koja pripremaju svaki
plan. Plan za vanredne dogaĊaje vremenom postaje zastareo i treba ga
periodiĉno testirati i uveţbavati. Postoje nekoliko vrsta testiranja:
revizija, analiza i simulacija katastrofa.

Pošto sve mere i metode zaštite pomaţu da se spreĉe vanredni dogaĊaji u

IKT sistemu, praktiĉno postoje meĊuzavisnosti sa svim kontrolama
zaštite, od kojih su najvaţnije: analiza rizika, fiziĉka i zaštita od uticaja
okruţenja, upravljanje incidentom, operativne kontrole i politike zaštite.

- 598 -
4. KLJUĈNI TERMINI

Hitna intervencija: odgovor na hitni sluĉaj kao što su poţar, poplava,

prirodna katastrofa, teroristiĉki napad i sl., da bi se zaštitili ţivoti,
ograniĉila šteta i smanjio uticaj rada IS.
Hladna lokacija: prazan, rezervni objekat izvan lokacije organizacije,
opremljen neophodnom infrastrukturom, pripremljenom za instalaciju
IKT opreme u sluĉaju vanrednog dogaĊaja.
Redundantna lokacija: opremljena sa sistemom identiĉnim primarnom
sistemu sa preslikavanjem podataka u rezervni sistem u realnom vremenu
i transparentnim oporavkom.
Nastavljanje poslovanja: aktivnosti za odrţavanje kritiĉnih poslova
organizacije u toku vanrednog dogaĊaja.
Operacija bekapovanja: stvaranje rezervnih kopija programa i podataka
za izvršavanje bitnih zadataka posle prekida rada, nastavljanje rada i
potpun oporavak IKT sistema.
Oporavak: restauracija objekata IKT sistema posle fiziĉkog uništenja ili
glavnog oštećenja.
Plan nastavljanja poslovanja: procedure i informacije razvijene,
povezane i odrţavane u gotovosti za upotrebu u sluĉaju vanrednih
dogaĊaja ili prirodne katastrofe.
Uzajamno bekapovanje: dve organizacije sa sliĉnim konfiguracijama
sistema obezbeĊuju rezervne kopije (bekapovanje) jedna drugoj u
sluĉaju vanrednog dogaĊaja.
Vruća lokacija: lokacija sa hardverom, softverom i mreţnom
instalacijom, kompatibilnom primarnoj instalaciji IKT sistema
organizacije.

- 599 -
5. LITERATURA

1. Bahan C, The Disaster Recovery Plan, http://www.sans.org,

2003.
2. Canada, A Guide to Business Continuity Planning, Last modified
2/3/2005,
http://www.ocipep.gc.ca/info_pro/self_help_ad/general/busi_cont
_e.asp, 2005.
3. Freeman W., Business Resumption Planning: A Progressive
Approach, Version 1.2f, SANS Institute, http://www.sans.org,
2002.
4. Humphrey A., Beyond Buy-In: The Case for Executive Level
Involvement in Developing a Business Continuity Plan, GIAC
Security Essentials Certification (GSEC), http://www.gsec.org,
March 9, 2005.
5. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
6. Moe Calvez, The Virtual Machine: A Tool for Business
Continuity Planning, http://www.sans.org, 2004.
7. NIST SP 800-12, An Introduction to Computer Security: The
NIST Handbook, http://csrc.nist.gov/publications, 1995.
8. NIST SP 800-3, "Establishing a Computer Incident Response
Capability", http://csrc.nist.gov/publications, 1999. NIST SP 800-
61, Computer Security Incident Handling Guide,
http://csrc.nist.gov/publications, 2004.
9. Office of Critical Infrastructure Protection and Emergency
Preparedness, Palermo, D, ―The Crisis Facing American
Business‖, Disaster Recovery Journal, Volume 18. Issue 1
(Winter 2005): 1-4. 7, http://www.drj.com/articles/win05/1801-
01.html, 2005.
10. Ridgway L. E., Disaster Recovery: Survivability & Security.
Version 1.4b GIAC Practical Assignment, 27 October 2003.
11. Russell L. B., Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery,
brand@lll-crg.llnl.gov, 1990.
12. SANS Institute, Introduction to business continuity planning,
http://www.sans.org, 2002. 11
13. USA CERT, http://www.uscert.org, 2005.

- 600 -
14. Velliquette D., Computer Security Considerations in Disaster
Recovery Planning, GIAC Security Essentials Certification
(GSEC) V1.4b Option1, http://www.gsec.org, 2004.

- 601 -
9. NADZOR I KONTROLA SISTEMA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja razumećete:

- principe i značaj servisa nadzor i kontrola sistema zaštite

- razvoj procesa nadzora i kontrole sistema zaštite
- strategije za nadzor i kontrolu sistema zaštite
- značaj razvoja kapaciteta (tim, alati) za nadzor i kontrolu
- značaj analize rezultata nadzora i kontrole sistema zaštite

Savremeni poslovni sistemi, drţavna uprava i lokalne samouprave

sve više zavise od sistema IKT zaštite. Da bi se izbegli ili spreĉili rizici
nepropisnog korišćenja, neovlašćenog pristupa, prisluškivanja podataka,
pronevera, otkrivanja osetljivih informacija, prekidanja kritiĉnih
operacija i uvoĊenja beţiĉne IKT tehnologije koja eskalira ove faktore
rizika, nuţno je obezbediti neprekidan nadzor i regularnu kontrolu
(auditing) sistema IKT zaštite. Da bi bili efektivni faktor odgovornosti u
zaštiti, kontrolori zaštite (auditori) u IKT sistemima moraju: biti
osposobljeni da evaluiraju sistem zaštite i ponude preporuke za
smanjenje bezbednosnog rizika na prihvatljivi nivo; posedovati
odgovarajuća znanja, veštine i sposobnosti i imati na raspolaganju
adekvatne resurse i alate, da bi pratili brzi razvoj IKT i tehnologija
zaštite; izgraditi i neprekidno odrţavati i unapreĊivati kapacitete za
kontrolu zaštite. Na nivou velikih poslovnih sistema i drţavne uprave
treba izraditi Uputstva za kontrolu sistema IKT zaštite, koje bi bilo od
znaĉajne pomoći svakom kontroloru i entitetu za kontrolu zaštite u fazi
planiranja, razvoja strategije, implementacije kapaciteta i procene
rezultata kontrole.

Praksa nadzora i kontrole sistema zaštite ukazuje na niz slabosti od

kojih su najznaĉajnije: nedostatak formalnih mehanizama za planiranje i
formalnih politika zaštite; neadekvatna kontrola promene konfiguracija
programa; nepotpuno korišćenje kapaciteta zaštite u OS; instalacija ili
modifikacija programa bez adekvatne kontrole i izmene pretpostavljene
konfiguracije ili pasvorda; neaţuriranje definicija antivirusnih programa,
neadekvatni planovi za vanredne dogaĊaje i nastavak poslovanja;
neadekvatno pripisivanje odgovornosti u zaštiti; sporo objavljivanje
otkrivenih ranjivosti OS; nedovoljna svest o potrebi zaštite; nepotrebno
velika ovlašćenja pristupa korisnika i nedovoljno odvajanje duţnosti u

- 602 -
IKT sistemima; nedostatak osnovnih kontrola zaštite za upravljanja
programom zaštite, fiziĉki i logiĉki pristup, upravljanje promenama,
odvajanje duţnosti i.t.d.

Svi ovi statistiĉki pokazatelji rezultata kontrole, ukazuju da kontrolori

sistema zaštite treba da, u procesima upravljanja rizikom i kontrole
sistema zaštite, usmere paţnju na upravljanje sistemom zaštite i
implementaciju kontrola zaštite.

- 603 -
1. PREGLED PRINCIPA KONTROLE SISTEMA ZAŠTITE

Kontrolni tragovi koriste se za otkrivanje penetracije u raĉunarski

sistem ili mreţu i za otkrivanje korišćenja objekata sistema u cilju
identifikovanja eventualnih zloupotreba. Zavisno od kontrolora,
kontrolni tragovi mogu biti ograniĉeni na specifiĉne dogaĊaje ili
obuhvatati sve aktivnosti u sistemu. Mehanizmi za kontrolu sistema
zaštite treba da obezbeĊuju kontrolu svakog pristupa sistemu, kao i
svakog pristupa osetljivim datotekama [9].

Funkcija kontrole sistema zaštite obezbeĊuje nezavisnu evaluaciju

politika, procedura, standarda, mera i prakse zaštite IKT sistema
organizacije od gubitaka informacija, oštećenja, nenamernog otkrivanja,
ili uskraćivanja raspoloţivosti. Najobimniji deo poslova obuhvata
procenu kontrola (mehanizama i protokola) zaštite IKT sistema za opštu
podršku, ili za glavnu aplikaciju. Proces kontrole zahteva testiranje i
kontrolu pristupnih puteva i taĉaka, koji zavise od stepena povezanosti
sistema u IKT okruţenju.

Bezbednosni ciljevi kontrole zaštite, samog sistema zaštite i/ili u

kontekstu evaluacije programa zaštite i sl., su da mehanizmi kontrole
moraju omogućiti:

1. reviziju obrazaca pristupa pojedinaĉnim objektima sistema,

istorije pristupa specifiĉnih procesa i korisnika i korišćenje
razliĉitih mehanizama zaštite,
2. otkrivanje ponovljenih pokušaja zaobilaţenja mehanizma zaštite,
ovlašćenih i neovlašćenih korisnika,
3. otkrivanje svakog korišćenja privilegija,
4. faktor odvraćanja napadaĉa koji uobiĉajeno pokušava zaobići
mehanizme zaštite i
5. dodatni faktor poverenja korisnika da će svi pokušaji zaobilaţenja
ili proboja mehanizama zaštite biti registrovani i otkriveni.

Korisnici mehanizma za kontrolu mogu se podeliti u grupu kontrolora -

korisnika sa pravima kontrolora, administratora sistema (za niţe nivoe
kontrole), ili administratora zaštite, koji biraju dogaĊaje koje sistem treba
da registruje, postavljaju kontrolne markere koji omogućavaju
registrovanje dogaĊaja i analiziraju kontrolne tragove i korisnika sistema-
ukljuĉujući administratore, operatore, programere i druge korisnike, koji

- 604 -
ne samo što generišu kontrolne dogaĊaje, nego moraju razumeti da
kontrolni mehanizmi postoje i koji uticaj oni imaju na njih, što je
presudno za faktore odvraćanja i postizanja bezbednosnih ciljeva.

1.2. Aspekti efektivnog procesa kontrole zaštite

Identifikacija/Autentifikacija obezbeĊuje logovanje na sistem i

normalno zahteva da korisnik unese korisniĉko ime, oĉita token,
magnetsku ili smart karticu sa biometrijskim identifikatorima i unese
pasvord ili smart karticu za autentifikaciju. Bez obzira da li je ova
informacija validna ili ne, izvršavanje procedure logovanja je kontrolni
dogaĊaj, a unesena informacija u log datoteku smatra se kontrolnom
informacijom. U sluĉaju da unesena informacija nije prepoznata kao
validna, sistem ne treba da registruje ovu informaciju u log datoteku.
Razlog za to je, što korisnik moţe uneti pasvord kada sistem traţi
korisniĉko ime (ID) za logovanje. Ako se informacija upiše u kontrolni
trag, kompromitovaće pasvord i bezbednost sistema. Savremeni
operativni sistemi spreĉavaju upisivanje pasvorda u log datoteku
kontrolnih tragova, pa je ovaj rizik izbegnut. Prednost registrovanja
identifikacionih informacija je lakše otkrivanje pokušaja proboja sistema
zaštite i otkrivanje identiteta napadaĉa u procesu forenziĉke istrage
kompjuterskog incidenta.

Administrativni aspekt obuhvata odgovorna lica koja koriste kapacitete

za kontrolu sistema zaštite i sprovode procedure kontrole. Funkciju
kontrolora zaštite u sistemima do bezbednosnog nivoa EAL2 (CC
kriterijumi evaluacije) mogu obavljati operateri i administratori sistema,
a za sisteme nivoa EAL3 i više kontrolu zaštite treba da obavljaju posebni
operateri ili administratori zaštite (kvalifikovani kontrolori zaštite), [8].

Dizajn sistema treba da sadrţi mehanizam, koji poziva funkciju kontrole

na zahtev administratora zaštite i koji odreĊuje da li dogaĊaj treba da
bude unesen u logo datoteku kao kontrolni trag. Ako nije implementirana
preselekcija dogaĊaja, onda se moraju odabrati dogaĊaji za registrovanje
u log datoteku kontrolnih tragova. Kontrolori moraju biti sposobni da
izaberu bezbednosno relevantne dogaĊaje za registrovanje u log datoteku
kontrolnih tragova i da rekonfigurišu log datoteku, na bazi identiteta
korisnika, bezbednosne klasifikacije objekata IKT sistema ili analize
incidenata i rizika.

- 605 -
Zaštita kontrolnog mehanizma od neovlašćenog pristupa i kontrolnih
tragova u log datoteci je obavezna. Podaci o kontrolnim tragovima su,
najmanje, osetljivi podaci. Uklonjeni mediji iz sistema koji sadrţe
kontrolne tragove, moraju se fiziĉki zaštititi i sanirati/odlagati u skladu sa
propisanom procedurom fiziĉke zaštite i saniranja osetljivih elektronskih
medija za ponovnu upotrebu. Bezbednosni zahtevi za mehanizam
kontrole sistema zaštite su sledeći, [8]:

1. Mehanizam za registrovanje kontrolnih dogaĊaja treba da bude

zaštićen od neovlašćenog pristupa, modifikacije ili zaobilaţenja;
2. Kontrolni trag treba da bude zaštićen sa mehanizmom zaštite
operativnog sistema od neovlašćenog pristupa i modifikacije;
3. Aktiviranje/dezaktiviranje kontrolnog mehanizma treba da bude
deo mehanizama zaštite operativnog sistema i da ostane
nepristupaĉan za neovlašćene korisnike.

- 606 -
2. RAZVOJ STRATEGIJE ZA NADZOR I KONTROLU ZAŠTITE
IKT SISTEMA
Standarde i uputstva za kontrolu zaštite IKT sistema propisuje i
donosi nekoliko meĊunarodnih organizacija, od kojih su najznaĉajnije:
ISACA (The Information Systems Audit and Control Association) i
ISACF (The Information Systems Audit and Control Foundation), koja je
izdala set uputstava za kontrolu sistema zaštite - COBIT (Control
Objectives for Information and Related Technology).
Entiteti za kontrolu, bez obzira na veliĉinu, treba da budu osposobljeni da
razviju/uspostave kapacitete za kontrolu, adekvatne za veliĉinu, strukturu
i potrebe organizacije.
Sa aspekta normativnog regulisanja, nadzor i kontrola sistema zaštite
treba da budu obuhvaćeni i nacionalnim Zakonom o zaštiti informacija u
IKT sistemima i Zakonom o borbi protiv visokotehnološkog
(kompjuterskog) kriminala. Na bazi normativnih okvira i usvojenih
standarda, svaka organizacija treba da izraditi Uputstvo za nadzor i
kontrolu zaštite IKT sistema, koje mora obuhvatiti, najmanje, procese:
planiranja kontrole zaštite, razvoja i poboljšanja strategije za razvoj
kapaciteta za kontrolu sistema zaštite, implementacije kapaciteta za
kontrolu sistema zaštite, merenja i nadzora funkcionisanja procesa
kontrole sistema zaštite [10].
2.1. Planiranje procesa kontrole sistema zaštite
Za izradu plana ili poboljšavanje procesa kontrole treba izvršiti sledeće
korake:
a. definisati misiju, ciljeve, obim i granice razvoja kapaciteta za
kontrolu zaštite,
b. proceniti vlastite kapacitete za kontrolu sistema zaštite (zakonski
okvir, ograniĉenja u izveštavanju, okruţenje procesa kontrole,
bezbednosne ranjivosti, znanja i veštine tima/kontrolora,
automatizovane alate i troškove kontrole),
c. planirati proces kontrole sopstvenim ili iznajmljenim kapacitetima za
kontrolu (povezati bezbednosne ciljeve sa procesom kontrole
planiranim za postizanje tih ciljeva i obezbediti informacije
raspoloţive na Internetu za istraţivanje i obuku) i
d. planirati sistem merenja procesa kontrole i monitoringa rezultata
kontrole.

- 607 -
a. Definisanje misije i ciljeva razvoja kapaciteta za kontrolu sistema
zaštite treba izvršiti u planu, sa eksplicitnim navoĊenjem odgovornosti
autoriteta i izvršioca kontrole. Ovo pomaţe za identifikovanje tipova
alata, potrebnih znanja, sposobnosti i veština i potrebne obuke
kontrolora. Plan treba dimenzionisati najmanje za srednjoroĉni period (3-
5 godina). Najznaĉajniji potencijalni ciljevi za uspostavljanje kapaciteta
za kontrolu sistema zaštite su, [8]:

 obezbediti pravovremenu podršku za neophodno poboljšanje procesa

kontrole zaštite;
 podrţati performanse procesa kontrole;
 dopuniti proces kontrole sa procenom efektivnosti sistema zaštite;
 obezbediti nezavisnu kontrolu zaštite, tako da se rizik moţe proceniti,
prihvatiti/smanjiti;
 podrţati zahteve za digitalnu forenziĉku istragu i analizu;
 obezbediti podršku za sofisticiranu analizu i ekstrakciju podataka i
 obezbediti mišljenje i procenu kontrolora zaštite u procesu razvoja
sistema zaštite.

U izgradnji kapaciteta za kontrolu sistema zaštite najmanje treba:

 proceniti spremnost kapaciteta i šta je rentabilno implementirati sa

datim resursima,
 konsultovati zakon za kompjuterski kriminal (testiranje na proboj,
izveštavanje, prava),
 definisati potencijalne odgovornosti,
 izvršiti bezbednosnu proveru, posebno za kapacitete TTPS i
 razmotriti uticaj zakonskih zahteva za obavezan pristup
informacijama.

Definisanje obima i granica kontrole sistema zaštite obuhvata iskusni

personal i kapacitete za kontrolu zaštite - relevantne alate, tehnike i
praksu za obavljanje zadataka kontrole. Za procenu broja sistema i
proizvoda zaštite za kontrolu kontrolor prikuplja informacije o
infrastrukturi IKT sistema da bi razumeo uslove i okruţenje za proces
kontrole. U PRILOGU III 9A dat je primer upitnika, na osnovu kojeg se
prikupljaju te informacije.

- 608 -
U praksi zaštite sve ĉešći je sluĉaj da organizacije vlastitim kapacitetima
samo planiraju proces regularne (godišnje) kontrole (auditing) svog
sistema IKT zaštite, dok proces kontrole izvršavaju spoljni, nezavisni i
akreditovani kontrolori/timovi za kontrolu. Vežba GIII P9A razvijena je
sa ciljem da se specijalisti zaštite obuĉe i samostalno vode proces
planiranja i izrade Plana za kontrolu sistema IKT zaštite.

b. Procena vlastitih kapaciteta za kontrolu sistema zaštite identifikacija

objekata IKT sistema i bezbednosnog rizika procesa kontrole je prvi
korak. Teško je oĉekivati da jedan kontrolor ima sva potrebna znanja i
sposobnosti, pa se preporuĉuje formiranje tima za kontrolu. Sakupljanje i
dokumentovanje informacija o sistemu, podacima i aplikacijama treba da
obuhvati:

 znaĉaj i prirodu programa i funkcija sistema,

 osetljivost ili poverljivost procesiranih informacija,
 tipove raĉunara koji vrše procesiranje (izolovan, distribuiran ili
umreţen),
 specifiĉni hardver i programi koje sadrţi konfiguracija raĉunarskog
sistema,
 vrstu pomoćnih programskih alata za dodavanje, izmenu, brisanje
podataka u datotekama, bazama i bibliotekama programa,
 vrstu alata za restrikciju pristupa programima i podacima,
 nivo umreţavanja, mogućnost slanja/preuzimanja informacija,
barijere i druge mreţne kontrolne ureĊaje,
 osnovne tipove i obim znaĉajnijih kupljenih programa koji se koriste,
 osnovne tipove i obim znaĉajnijih programa razvijenih u organizaciji,
 naĉin (interaktivni, neinteraktivni) i mesto unosa podataka i
izveštavanja,
 pribliţan broj transakcija i finansijskih iznosa koje procesira svaki
znaĉajniji sistem,
 organizacione promene i kljuĉni personal zaposlen u IKT sistemu,
 oslanjanje na druge organizacije u procesiranju,
 rezultate poslednje interne i eksterne kontrole i
 usaglašenost sa relevantnim normativima i standardima.

- 609 -
Formiranje tima za kontrolu, procena znanja, sposobnosti i veština
internih i eventualno iznajmljenih ĉlanova, kljuĉna je komponenta
planiranja, izgradnje ili unapreĊenja kapaciteta za kontrolu zaštite.
Rangiranje znanja, sposobnosti i veština kontrolora sistema zaštite,
najĉešće se vrši prema skali:

 stručnjak (ekspert): ima veliko iskustvo, moţe instruisati druge za

izvršavanje zadataka kontrole sistema zaštite,
 profesionalac: moţe izvršiti zadatke kontrole sistema zaštite bez
posebnih priprema za istraţivanje oblasti ili sticanje odreĊenih
veština,
 sposoban: veruje da moţe izvršiti zadatke kontrole sistema zaštite, ali
zahteva neku pomoć, ili odreĊeno vreme za pripremu, istraţivanje
oblasti i sticanje odreĊenih veština i
 jako zainteresovan: ima jaku ţelju i interes za sticanje znanja, veština
i sposobnosti za rad u oblasti kontrole sistema zaštite.

Pojam posedovanje veština najĉešće podrazumeva posedovanje, znanja,

veština i sposobnosti i meri se parametrom KSA (knowledge, skills,
abilities), koji se tipiĉno koristi za opisivanje radnih mesta i oglašavanje
za slobodna radna mesta, ukazujući na atribute koji se zahtevaju za
odreĊeni posao, pored zvaniĉnog stepena obrazovanja, [6]:
Znanje - organizovan korpus informacija, ĉinjenica, principa ili
procedura koje, kada se primene, omogućavaju izvršavanje
odgovarajućeg posla i predstavlja osnovu za izgraĊuju veština i
sposobnosti. Primer: poznavanje alata i tehnika za uspostavljanje
logiĉke kontrole pristupa IKT sistemu.
Veština - sposobnost veštog manuelnog, verbalnog ili mentalnog
manipulisanja ljudima, idejama i stvarima, koja se moţe demonstrirati i
pokazati stepen profesionalizma. Primer: obuĉenost lica za rukovanje sa
PC, izradu tabela u Excel-u i.t.d.
Sposobnost - mogućnost da se izvršavaju neke poslovne funkcije,
primenjujući ili koristeći bitna znanja; dokazuje se kroz aktivnosti koje se
zahtevaju za obavljanje nekog posla.
Primer: primena znanja o logiĉkoj kontroli pristupa za evaluaciju
adekvatnosti implementacije tih kontrola u sistem zaštite.

- 610 -
Pregled znanja, veština i sposobnosti za efektivno izvršavanje procedura
kontrole odreĊenih komponenti sistema zaštite u IKT okruţenju, koje
treba da pokaţu kontrolori (Tabela 2.1), razliĉiti tehniĉki specijalnosti,
ĉlanovi tima za kontrolu (Tabela 2.2), dat je u PRILOGU III 9B, [2].

Za izvršavanje zadataka kontrole sistema zaštite, organizacija moţe

uspostaviti partnerski i ugovorni odnos sa specijalizovanom
organizacijom za auditing. Ovakav aranţman moţe imati širok spektar
mogućih oblika saradnje: od iznajmljivanje kompletnog tima za kontrolu
sistema zaštite, preko iznajmljivanja pojedinih visoko - specijalizovanih
struĉnjaka, do davanja konsultantskih usluga ili iznajmljivanja
specijalizovanih hardversko softverskih alata i drugih kapaciteta za
kontrolu sistema zaštite.

Identifikacija i izbor automatizovanih alata za kontrolu zaštite, kao i

specijalizovani kontrolori koji poseduju znanje i veštinu za njihovu
upotrebu, bitni su za identifikovanje ranjivosti sistema u toku izvršavanja
procesa kontrole sistema zaštite:

 Alati za ekstrakciju podataka u softveru za logiĉku kontrolu pristupa,

mogu identifikovati kršenje principa razdvajanja duţnosti
privilegovanih korisnika,
 Krekeri pasvorda mogu identifikovati korišćenje pretpostavljenog ili
lakog pasvorda,
 Sniferski programi mogu identifikovati otvoren prenos pasvorda ili
osetljivih informacija,
 Skeneri mogu pomoći kod identifikovanja zaštitnog profila
raĉunarskog sistema/mreţe,
 Lokatori modema mogu pomoći da se identifikuju nebezbedni
modemi.

Većina organizacija ima potrebu da koristi usluge specijalizovanih

partnerskih organizacija u procesu izbora adekvatnih automatizovanih
alata za kontrolu sistema zaštite, kao i u procesu obuke i izbora
osposobljenih kontrolora za njihovo korišćenje. U PRILOGU III 9C,
Tabela 2.3, prikazana su pitanja i sugestije koje treba razmatrati u
procesu evaluacije i izbora bezbednosnih softverskih alata.

- 611 -
Bilo da formira ili modernizuje kapacitete za kontrolu sistema zaštite,
organizacija treba da razvije proces selekcije, evaluacije i revizije
programskih alata za kontrolu zaštite. Preporuĉuju se sledeći koraci:

 istraţivanje raspoloţivih alata i navoĊenje nekoliko u svakoj

kategoriji,
 razmena iskustava sa partnerskim organizacijama o pogodnosti alata,
 odreĊivanje stepena potreba za alatima za specifiĉne platforme,
 odreĊivanje metodologije za evaluaciju i izbor,
 razvoj procedure za obuku korisnika i
 razvoj procesa za kontrolu rentabiliteta alata.

Razvoj metodologije za izbor i implementaciju programskih alata za

kontrolu sistema zaštite ima višestruke prednosti: izabrani alat je koristan
i za kontrolni tim i za proces kontrole; ne gubi se vreme na neadekvatne
alate; minimizira se uticaj na sistem organizacije; minimiziraju se
troškovi obuke i alata; obezbeĊuju se efektivnije i preciznije preporuke
za kontrolu; obezbeĊuju se neophodna znanja kontrolora/tima za
kontrolu; obezbeĊuje se obuka i stiĉu iskustva za implementaciju alata i
evaluaciju rezultata kontrole. Revizija i izbor alata za kontrolu zaštite
kritiĉan je faktor za razvoj jakih kapaciteta za kontrolu sistema zaštite.

Procena troškova procesa kontrole nezaobilazno je pitanje, pošto obuka

kontrolora, iznajmljivanje struĉnih konsultanata i uopšte odrţavanje
vlastitih kapaciteta za kontrolu sistema zaštite zahteva znaĉajne troškove
za svaku organizaciju.

c. Planiranje procesa kontrole sopstvenim ili iznajmljenim kapacitetima

za kontrolu sistema zaštite moţe se izvršiti sopstvenim ili iznajmljenim
kapacitetima. Organizacija koja ima razvijene kapacitete za kontrolu
sistema zaštite treba da odredi kriterijume za planiranje i izbor projekata
kontrole, radi sopstvenog ugleda. Takvi kriterijumi mogu ukljuĉivati
sledeće:

 sistem treba da bude kritiĉan, prema postavljenom bezbednosnom

cilju,
 sistem treba da ima pridruţeni rizik (poverljivi podaci i distribuirani,
udaljeni pristup),
 saradnja vlasnika sistema za redukciju rizika od eventualnog
oštećenja u toku testiranja,

- 612 -
 sistem treba da bude na podnošljivom nivou kompleksnosti za tim za
kontrolu i
 proces kontrole mora se uklopiti u godišnji i kratkoroĉni plan.

Generalno, kod planiranja kontrole sistema zaštite, treba koristiti

rotacioni metod za izbor sistema kojeg treba kontrolisati, na bazi voĊenja
spiska kljuĉnih sistema za regularnu godišnju kontrolu u odreĊenim
vremenskim periodima. Ovakav metod je posebno znaĉajan za planiranje
kontrole sistema zaštite u visoko distribuiranim sistemima.

Za izgradnju ili dogradnju kapaciteta za kontrolu sistema zaštite zahteva

se veliki broj razliĉitih aktivnosti, koje variraju u zavisnosti od ciljeva
organizacije koja vrši kontrolu. U tom smislu moguće je razviti radni
dokument (PRILOG III 9D, Tabela 2.4), koja moţe pomoći u
planiranju i odreĊivanju aktivnosti koje su potrebne da se ispune
postavljeni ciljevi kontrole i odredi adekvatan tim za izvršavanje tih
aktivnosti. Koristeći referentnu Tabelu 2.4, mogu se
uspostaviti ciljevi kontrole, povezati ciljeve i prateće aktivnost i
identifikovati nedostajući resursi. Kompletiranje ove tabele moţe
zahtevati nekoliko iteracija. Za kompletiranje tabele, organizacija treba
prvo da odredi da li cilj zahteva nove ili modifikovane kapacitete. Za
organizacije koje uspostavljaju poĉetne kapacitete za kontrolu zaštite
IKT sistema, tabela
moţe biti od koristi ako se razmatraju sve raspoloţive mogućnosti.

Korisni resursi za planiranje, razvoj i odrţavanje kapaciteta za kontrolu

mogu se naći na brojnim Internet web lokacijama, od kojih su
najpoznatiji: www.isaca.org , www.itaudit.org , www.auditnet.org,
www.cert.org, www.sans.org i.t.d.

d. Planiranje procesa merenja i monitoringa rezultata kontrole

Organizacije koje se profesionalno bave kontrolom zaštite IKT sistema,

treba da mere i monitorišu rezultate procesa svake kontrole zaštite, da bi
procenile performanse sopstvenog sistema za kontrolu. Za efektivno
merenje i monitoring potrebno je jasno definisati misiju i ciljeve
kontrole, uspostaviti dugoroĉni strateški plan (3-5 godina) i kratkoroĉni
plan rada.

- 613 -
Rezultate merenja performansi sistema kontrole treba uporediti sa
uspostavljenim ciljevima i izveštavati o progresu. Primeri opisa
postavljenih ciljeva kontrole zaštite IKT sistema su, [10]:

 Kontrola i evaluacija rezultata i preporuke su efektivni;

 Kontrola i evaluacija rezultata zadovoljavaju profesionalne standarde
i legalne zahteve;
 Kapaciteti za kontrolu zaštite IKT sistema su takvi da će privući i
zadrţati visoko kvalifikovane, motivisane i posvećene struĉnjake;
 Radno okruţenje će razviti i vrednovati poverenje, otvorenu
komunikaciju i profesionalne rezultate.

Iako auditing organizacije definišu svoje planove i kapacitete prema

svom okruţenju, potrebama i sposobnostima i razlikuju se u pristupu
procesu kontrole, svaka treba da je rezultatski orijentisana i da:

 monitoriše proces kontrole i

 procenjuje (evaluira) performanse kapaciteta za kontrolu.

Za proces kontrole zaštite IKT sistema, treba definisati sistem relevantnih

indikatora performansi (tj. benčmarking sistem) internih i eksternih
kapaciteta za kontrolu svakog pojedinaĉnog elementa zaštite koji se
kontroliše. Primer: benĉmarking kompetentnosti tima za kontrolu,
zahteva da svako IKT odeljenje treba da ima 65% svojih kontrolora sa
CISA (Certified Information Systems Auditor) sertifikatom, ili sa
diplomom fakulteta kompjuterskih nauka ili menadţmenta informacionih
sistema.

Procenjujući performanse kritiĉnih faktora uspeha (CSF), mere se

servisi, koje treba da pruţe kapaciteti za kontrolu i uporeĊuju sa
planiranim ciljevima. Ovo zahteva identifikaciju kljuĉnih mera
performansi i/ili CSF. Procenu kapaciteta za kontrolu zaštite treba vršiti
redovno.

- 614 -
Postizanje strategijskih ciljeva moţe se demonstrirati poreĊenjem
rezultata kvantitativnih i kvalitativnih kriterijuma za merenja
performansi i ciljeva. Za definisane strategijske ciljeve, mogu se koristiti
sledeći kriterijumi merenja rezultata kontrole:

 finansijska dobit ,
 poboljšanje sistema zaštite,
 dati predlozi mera za korekciju sistema zaštite i sl.

Proces evaluacije treba vršiti periodiĉno da bi se procenio stvarni progres

u postizanju dugoroĉnih ciljeva procesa kontrole sistema zaštite. Ovo se
posebno odnosi na preporuĉene aktivnosti za kontrolore iz prethodnog
procesa kontrole, koje treba aktivno monitorisati, razmatrati i najmanje
jedanput godišnje izveštavati o rezultatima analize, da bi se odredile
potrebne aktivnosti u odreĊenim oblastima sistema zaštite. Uzorci
kompletiranih zadataka treba da se revidiraju da bi se odredila
usklaĊenost sa standardima, a rezultati - za korekciju bilo koje
identifikovane ranjivosti. Potrebno je evaluirati administriranje svakog
kapaciteta za kontrolu sistema zaštite, ukljuĉujući merenja kljuĉnih
performansi, da bi se odredila rentabilnost i efikasnost. Periodiĉno treba
obezbediti nezavisnu reviziju kontrole kvaliteta.

Procenu zadovoljstva kontrolisanog entiteta sa procesom kontrole i

izvršenim servisima kontrole treba vršiti u regularnim intervalima, da bi
se identifikovale slabosti i postavili ciljevi za poboljšanje kapaciteta za
kontrolu. U kontrolisanom entitetu treba izvršiti anketu koja obezbeĊuje
procenu:

 profesionalizma ĉlanova tima za kontrolu u ponašanju i izgledu,

 tehniĉkog razumevanja kontrolisane oblasti zaštite,
 sposobnosti usmene i pismene komunikacije sa personalom
kontrolisanog entiteta,
 efektivno korišćenje raspoloţivog vremena i drugih resursa,
 sposobnost odrţavanja pozitivnih i produktivnih odnosa sa
personalom kontrolisanog entiteta i
 profesionalizam u izveštavanju kontrolisanog entiteta o nalazima
kontrole, ukljuĉujući poverljivost izveštavanja, da bi se sistem
zaštitio od korišćenja eventualno otkrivenih ranjivosti za neovlašćene
pristupe i napade hakera.

- 615 -
Izveštavanje o progresu procesa kontrole u skladu sa postavljenim
ciljevima treba dostavljati menadţmentu organizacije koja vrši kontrolu,
a u zavisnosti od nalaza treba oĉekivati iniciranje odgovarajućih
aktivnosti menadţmenta.

Definisanje benčmark indikatora kapaciteta za kontrolu sistema zaštite

treba da obuhvati sledeće faktore:

Nezavisnost kapaciteta za kontrolu od oblasti koje kontrolišu generalno

se podrazumeva, da bi kontrola bila objektivna. Svaki ĉlan tima treba da
potpiše izjavu politike o nezavisnosti i objektivnosti kontrole.

Profesionalna etika i standardi kapaciteta za kontrolu zaštite treba da

budu usklaĊeni sa etiĉkim principima i standardima svih aspekata rada
profesionalnih kontrolora zaštite, koje propisuje meĊunarodna asocijacija
ISACA (Information Systems Audit and Control Association) ili sa
FISMA (Federal Information System Control Audit Manual), NIST,
SAD. Merenje usklaĊenosti moţe se obezbediti monitoringom
performansi kapaciteta za kontrolu i procenom usklaĊenosti, internom
revizijom izabranih procesa kontrole i procenom usklaĊenosti i drugim
metodama.

Kompetentnost i zadržavanje kvalifikovanog osoblja: Benĉmark sistem u

ovoj oblasti moţe ukljuĉiti procenat ĉlanova tima za kontrolu koji imaju
univerzitetsku diplomu (VSS) u specifiĉnim disciplinama. Na primer
benĉmark indikatori mogu biti: da 65% ĉlanova ima CISA sertifikat,
diplomu odgovarajućih fakulteta ili menadţmenta IKT sistema, ili da
svaki kontrolor u odnosu na zahtev za neprekidnim profesionalnim
obrazovanjem dobije svake godine po 20 ĉasova neprekidnog
profesionalnog obrazovanja, ili 120 ĉasova u tro-godišnjem periodu.
Planiranje i izrada plana kontrole obezbeĊuje regularnu i nezavisnu
kontrola. Za merenje stepena adekvatnosti plana, mora postojati centralni
repozitorij informacija o svim procesima kontrole, kritiĉnim
aplikacijama, granicama i obimu, funkcijama i vrsti kritiĉnih faktora i dr.
Merenje se sastoji u proceni taĉnosti informacija u centralnom
repozitorijumu, poreĊenjem sa referentnim organizacijama za kontrolu.

Merenje performansi procesa kontrole treba obezbediti da bi se postigli

ciljevi i zadovoljili profesionalni standardi kontrole. Proces kontrole
treba na odgovarajući naĉin nadgledati, da bi kontrolori bili sigurni da su

- 616 -
dobili dovoljno pouzdanih, relevantnih i korisnih dokaza da su ciljevi
kontrole postignuti. Nalazi procesa kontrole i zakljuĉci treba da budu
potkrepljeni sa odgovarajućom analizom i interpretacijom ovih dokaza.
Mora se odrediti da li je rad izvršen u skladu sa planiranim budţetom i
vremenom i da li je završen u planiranom roku. Relevantni ciljevi i
odgovarajući sistem merenja moraju biti definisani u planu kontrole.

Primer 1:

Cilj: Stvarno vreme kontrole ne premašuje budţet za više od 10% za sve

izvršene zadatke.
Merenje: Akumulirati sva realna vremena i uporediti ih sa finansiranim
vremenom kontrole da bi se odredili kumulativni premašaji/podbaĉaji za
sve izvršene procese kontrole.
Primer 2:
Cilj: Terenski rad za 90% procesa kontrole mora se završiti u dato roku
(npr., 6 meseci).
Merenje: Odrediti % procesa kontrole završenih u specificiranom roku
(na bazi izveštaja).

Merenje sistema izveštavanja, forme i sadrţaja izveštaja, kojeg kontrolor

generiše po završetku procesa kontrole i dostavlja menadţmentu
kontrolisane organizacije, obavezno treba planirati. Izveštaj o kontroli
treba da sadrţi ciljeve, period rada, prirodu i opseg izvršenih aktivnosti i
primenjene standarde kontrole i da identifikuje organizaciju, lica kojima
se dostavlja i eventualne restrikcije o cirkulisanju. U izveštaju se moraju
navesti nalazi, zakljuĉci i preporuke koje se odnose na aktivnosti u
procesu kontrole, kao i sve rezerve ili kvalifikacije koje kontrolor ima u
odnosu na proces kontrole. U izveštaju mora postojati iskaz da se u
procesu kontrole i izveštavanja nisu otkrile informacije koje mogu
kompromitovati kontrolisani sistem. Izveštaj treba dostaviti u planiranom
roku, da bude od koristi svim zainteresovanim stranama. Moţe se
uspostaviti sledeći specifiĉni sistem merenja:

Cilj: 80 % nacrta izveštaja treba izraditi 30 dana nakon završetka

terenskog rada.
Merenje: Odrediti procenat izveštaja dostavljenih u planiranom roku
(merenom od završetka terenskog rada do dana dostavljanja izveštaja).

- 617 -
Merenje aktivnosti posle procesa kontrole zahteva uspostavljanje
procedure za odreĊivanje da li je menadţment kontrolisanog entiteta
preduzeo odgovarajuće aktivnosti u predviĊenom roku na bazi
prethodnih nalaza i preporuka. Rezultati kontrole i komentari kontrolora
ostaju kod menadţmenta kontrolisanog entiteta i treba uspostaviti
merenje stepena prihvatanja nalaza kontrolora od strane kontrolisanog
entiteta, odreĊivanjem procenta nalaza kontrole i specifiĉnog procenta
implementiranih nalaza u datom roku, na primer:

Cilj: menadţment kontrolisanog entiteta prihvata 90% preporuka iz

izveštaja.
Merenje: Odredi procenat preporuka iz izveštaja prihvaćenih u
formalnom odgovoru menadţmenta kontrolisanog entiteta, merenjem u
odreĊenom vremenskom periodu.
Cilj: kontrolisani entitet je implementirao 60 % preporuka iz izveštaja u
odreĊenom periodu.
Merenje: Odredi procenat preporuka iz izveštaja, implementiranih u
odreĊenom periodu.

- 618 -
3. REZIME

Praksa zaštite ukazuju da u procesima upravljanja rizikom i

kontrole zaštite, kontrolori treba da usmere paţnju na oblasti upravljanja
sistemom zaštite i implementacije kontrola zaštite.

Glavni principi, koji obezbeĊuju uspostavljanje efikasnih i efektivnih

kapaciteta za kontrolu zaštite IKT sistema (kontrolora/tima, tehnika i
alata, resursa za podršku), obuhvataju planiranje i definisanje: funkcija i
ciljeva kontrole, namene mehanizama za kontrolu, korisnika kontrolnih
mehanizama i svih aspekata efektivnosti procesa kontrole zaštite
(identifikacija/autentifikacija, administracija, dizajn i zaštita kontrolnog
mehanizma).

Na bazi normativnih okvira i usvojenih standarda, svaka organizacija

treba da definiše kapacitete za kontrolu zaštite-vlastite ili iznajmljene,
planira proces kontrole i izradi Uputstvo za nadzor i kontrolu zaštite IKT
sistema, koje mora obuhvatiti, najmanje, procese: planiranja, razvoja
kapaciteta za kontrolu, implementacije mehanizama za kontrolu, nadzora
funkcionisanja i evaluacije kvaliteta procesa kontrole i rezultata.

Za izradu plana kontrole, modifikaciju ili poboljšavanje procesa kontrole,

treba konzistentno izvršiti sledeće aktivnosti: definisati misiju i ciljeve
razvoja kapaciteta za kontrolu zaštite; proceniti postojeće kapacitete
(zakonski okvir, ograniĉenja u izveštavanju, okruţenje procesa kontrole,
ranjivosti, znanja i veštine kontrolora, alate i troškove kontrole); planirati
dinamiku procesa kontrole sopstvenim ili iznajmljenim kapacitetima,
povezati ciljeve kontrole sa aktivnostima procesa kontrole i obezbediti
informacije za rad, istraţivanje i obuku.

Kljuĉna komponenta kapaciteta za kontrolu sistema zaštite je formiranje

tima za kontrolu, ukljuĉujući procenu znanja, sposobnosti i veština
ĉlanova tima da izvrše sve zadatke kontrole. Rangiranje znanja,
sposobnosti i veština (knowledge, skills, abilities) - KSA kontrolora
sistema zaštite, najĉešće se vrši prema skali: stručnjak, profesionalac,
osposobljen i jako zainteresovan. Za obavljanje poslova kontrole
potrebni su veliko iskustvo i specifiĉne veštine kontrolora. Parametar
KSA se tipiĉno koristi za opisivanje i oglašavanje radnih mesta,
ukazujući na atribute koji se zahtevaju za odreĊeni posao, pored
zvaniĉnog stepena obrazovanja. Svaki ĉlan tima mora da poseduje

- 619 -
odgovarajući nivo opštih veština (skupljanje dokumentovanih dokaza,
intervjui, usmena i pismena komunikacija i upravljanje projektom
kontrole), ali ne mora imati sve zahtevane atribute, dok tim u celini treba
da ih poseduje.

Razvoj metodologije za izbor i implementaciju softverskih alata za

kontrolu sistema zaštite ima višestruke prednosti. Bilo da formira ili
modernizuje kapacitete za kontrolu zaštite, organizacija treba da razvije
proces selekcije, evaluacije i revizije softverskih alata za kontrolu zaštite
kroz: istraţivanje raspoloţivih alata, razmenu iskustava o pogodnosti
alata, odreĊivanje stepena potrebe za specifiĉnim alatima, odreĊivanje
metodologije za evaluaciju i izbor, razvoj procedure za obuku korisnika i
razvoj procesa za evaluaciju i kontrolu kvaliteta. Pregled i izbor
softverskih alata za kontrolu zaštite kritiĉan je faktor za razvoj jakih
kapaciteta za kontrolu sistema zaštite.

Organizacije za kontrolu zaštite, treba da monitorišu funkcionisanje

procesa kontrole i mere performanse i rezultate procesa svake kontrole
zaštite. Za efektivno merenje i monitoring potrebno je: jasno definisati
misiju i ciljeve kontrole, uspostaviti dugoroĉni i kratkoroĉni plan rada,
porediti rezultate merenja performansi sistema kontrole sa planiranim
ciljevima na osnovu benĉmark indikatora i izveštavati menadţment o
progresu. Treba meriti sve aktivnosti procesa kontrole zaštite, a kljuĉni
zahtev je izbor benĉmark indikatora za svaku aktivnost, na primer za
proces izveštavanja: odrediti procenat izveštaja dostavljenih u
planiranom roku (merenom od završetka terenskog rada do dana
dostavljanja izveštaja).

Posle dostavljanja izveštaja o kontroli, poverljivim kanalima i uz

garanciju da proces kontrole nije kompromitovao kontrolisani sistem,
rezultati i komentari ostaju u vlasništvu menadţmenta kontrolisanog
entiteta. Treba uspostaviti proceduru koja obavezuje menadţment
kontrolisanog entiteta da preduzme odgovarajuće aktivnosti u
predviĊenom roku, na bazi nalaza i preporuka kontrolora.

- 620 -
4. KLJUĈNI TERMINI

Administrator zaštite sistema (System Security Administrator): lice

odgovorno za bezbednost IKT sistema koje ima ovlašćenje da nameće
politiku zaštite legalnim korisnicima.
Bezbednosno-relevantni dogaĊaji (Security-Relevant Event): dogaĊaj
koji pokušava da izmeni bezbednosno stanje sistema ili da naruši politiku
zaštite sistema.
Kontrola (Audit): proces nezavisne kontrole i ispitivanja sistemskih i
aplikativnih programa, sistema zaštite, aktivnosti prakse zaštite i
upravljanja sistemom zaštite.
Kontrolisan dogaĊaj (Auditable Event): dogaĊaj koji se moţe izabrati i
logovati u datoteku kontrolnih tragova, kao bezbednosno relevantni i
dogaĊaje za oporavak sistema.
Kontrolni mehanizam (Audit Mechanism): hardversko softverski
modul koji se koristi za skupljanje, pregled i/ili ispitivanje aktivnosti
sistema.
Kontrolni trag (Audit Trail): skup registrovanih podataka koji
obezbeĊuju dokumentovane dokaze o procesima koji se koriste za
praćenje traga od originalne transakcije do odnosne snimljene
informacije i izveštaja, i/ili unazad od snimljene informacije i izveštaja
do komponente koja je izvora njihove transakcije.
Kontrolor (Auditor): ovlašćeno lice sa pravima izbora dogaĊaja za
kontrolu, podešavanja sistema za registrovanje tih dogaĊaja i analize
kontrolnih tragova.

- 621 -
5. LITERATURA

1. ISACA IS Auditing Procedure: Security Assessment Penetration

Testing and Vulnerability Analysis, Document #8,
http://www.isaca.org, 2004.
2. ISACA, IS Auditing Guideline: Application Systems Review,
Document # 060.020.020, http://www.isaca.org, 2003.
3. ISACA, IS Auditing Guideline: Audit Evidence Requirement,
http://www.isaca.org, 1999.
4. ISACA, IS Auditing Guideline: Planning, Document #
050.010.020, http://www.isaca.org, 2001.
5. ISACA, IS Auditing Procedure: Viruses and Other Malicious
Logic, Document #4, http://www.isaca.org, 2003.
6. ISACA, Standards for Information Systems Control
Professionals, http://www.isaca.org, 1999.
7. ISACA, Use of Risk Assessment in Audit Planning,
http://www.isaca.org, 2000.
8. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija
razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
9. NATIONAL COMPUTER SECURITY CENTER, A Guide to
Understanding Audit in Trusted Systems, NCSC-TG-001,
VERSION-2., http://www.nccc.org, 1987.
10. National State Auditors Association&U. S. General Accounting
Office, Management Planning Guide for Information Systems
Security Auditing, http://www.isaca.org, 2001.
11. www.auditnet.org; www.cert.org; www.rootshell.com;
www.sandstorm.com; www.sans.org; www.securityfocus.com;
www.securitysearch.net; www.sso.org/nasact/;
www.technotronic.com/.

- 622 -
10. SERTIFIKACIJA I AKREDITACIJA SISTEMA ZAŠTITE

0. UVOD

Po završetku ovog poglavlja razumećete:

- mtodologiju procesa sertifikacije i akreditacije (C&A):

uloge i odgovornosti, kategorije akreditacije,
dokumentacija, ...
- upravljanje procesom C&A:
faza predsertifikacije, faza sertifikacije,
faza akreditacije, faza postakreditacije

Sertifikacija je proces koji obuhvata procenu tehniĉkih i ne-teh-

niĉkih kontrola zaštite IKT sistema i obezbeĊuje neophodne informacije
da ovlašćeni menadţer donese valjanu odluku, zasnovanu na proceni
rizika, za puštanje sistema u rad. Sloţenost sistema je glavni problem u
procesu sertifikacije, jer što je sistem kompleksniji to je teţe temeljno
pregledati i evaluirati sve njegove komponente zaštite.

Akreditacija je autorizacija ili odobrenje IKT sistema za rad, a sprovode

je nedleţni menadţeri organizacije, kroz kvalitativnu kontrolu rada
upravljaĉkih, operativnih i tehniĉkih kontrola zaštite. Plan zaštite je
osnovni dokument koji se zahteva na uvid u procesu akreditacije, a po-
trebno je izvršiti i procenu rizika i evaluaciju sistema zaštite, ili sertifika-
ciju koja obezbeĊuje informacije potrebne menadţeru za izdavanje for-
malne izjave - akreditacije da je odobreno puštanje nekog IKT sistema u
rad, na prihvatljivom nivou rizika. Ova odluka se zasniva na implementa-
ciji planiranog skupa upravljaĉkih, oprativnih i tehniĉkih kontrola zaštite.
Akreditacijom sistema, rukovodstvo potvrĊuje da prihvata rizik pridruţen
tom sistemu. Formalizacija postupka akreditacije smanjuje mogućnost da
sistem bude pušten u rad, bez odgovarajuće kontrole menadţmenta. Posle
znaĉajnih promena u sistemu, okruţenju ili tehnologijama zaštite, treba
ponovo izvršiti akreditaciju, najmanje svake treće godine, a ĉešće ako je
u pitanju povećan rizik i veća mogućnost nastanka štete.

- 623 -
1. METODOLOGIJA PROCESA SERTIFIKACIJE I
AKREDITACIJE

1.1. Uloge i odgovornosti

Svaka organizacija treba da definiše uloge i odgovornosti za

proces sertifikacije i akreditacije (C&A), prema svojoj organizacionoj
strukturi, da bi na najbolji naĉin upravljale rizikom u odnosu na ciljeve i
misiju organizacije. Kljuĉne uloge u tipiĉnom C&A programu su: (1)
entitet za akreditaciju, imenovano telo/lice za akreditaciju (DAA-
Designated Accreditation Authority), (2) sertifikator, lice koje vrši
sertifikaciju i izdaje sertifikat, (3) rukovodilac programa ili vlasnik
sistema i (4) specijalista za zaštitu. Da bi se povećao integritet i
objektivnost pri donošenju akreditacione odluke, mogu se uvesti i
dodatne uloge. Broj uĉesnika u C&A procesu i njihove uloge zavise od
kompletnosti dokumenata zaštite, ovlašćenih lica, raspoloţivih resursa,
uloţenog napora u proces sertifikacije i bezbednosnih zahteva u odnosu
na, osetljivost i kritiĉnost sistema, [6].

Entitet za akreditaciju (DAA), obiĉno je stariji menadţer sa

ovlašćenjem da formalno odobri rad IKT sistema na prihvatljivom nivou
rizika, koji, podrazumeva se, u postupku akreditacije preuzima
odgovornost za rizik rada sistema u odreĊenom okruţenju. DAA ima
ovlašćenja da: nadgleda i utiĉu na budţet i operacije sistema u njihovoj
nadleţnosti; odobrava dokumenta o bezbednosnim zahtevima,
memorandume o sporazumevanju (MOU) i sva odstupanja od politike
zaštite; ne odobri rad sistema, ukoliko postoji neprihvatljiv rizik ili
zaustavi rad sistema, ako je sistem već u upotrebi.

Na osnovu informacija tima za sertifikaciju i procene rizika DAA moţe

formalno doneti odluku da: (1) izda punu akreditaciju, (2) izda
privremenu akreditaciju, ili (3) odbije akreditaciju sistema, ako je
preostali rizik neprihvatljiv. Odluka o akreditaciji dokumentuje se u
konaĉnom akreditacionom paketu, koji sadrţi izjavu o akreditaciji,
sertifikacioni paket i obrazloženje akreditacione odluke. U nekim
situacijama, moţe se ukljuĉiti više DAA, koji moraju postići saglasnost i
dokumentovati je u akreditacionom paketu.

- 624 -
Sertifikator je osoba odgovorna za procenu usaglašenosti IKT sistema sa
postavljenim bezbednosnim zahtevima za identifikaciju, procenu i
dokumentovanje rizika rada sistema, koordinaciju sertifikacionih
aktivnosti i konsolidaciju konaĉnog C&A paketa.
Sertifikator/sertifikacioni tim obezbeĊuje ekspertizu za voĊenje
nezavisne tehniĉke i ne-tehniĉke evaluacije sistema, na osnovu
bezbednosnih zahteva i kontrola sistema zaštite, dokumentovanih u planu
zaštite. Sertifikator procenjuje moguće pretnje, odreĊuje korektnost
implementacije kontrola zaštite i nivo preostalog rizika. Da bi se
saĉuvala nepristrasnost i nezavisnost sertifikacionog procesa, sertifikator
treba da bude nezavisan od vlasnika, korisnika i administratora zaštite
sistema. Organizaciona nezavisnost sertifikatora obezbeĊuje objektivnost
nalaza na osnovu kojih DAA donesi akreditacionu odluku.

Rukovodilac programa i vlasnik sistema predstavljaju interese korisnika

IKT sistema tokom celog ţivotnog ciklusa sistema. Rukovodilac
programa je odgovoran za sistem za vreme poĉetnog razvoja i akvizicije,
a brine se o troškovima, planu i izvršavanju plana akvizicije sistema.
Pošto je sistem isporuĉen i instaliran, podrazumeva se da je vlasnik
sistema odgovoran za sistem u toku rada, odrţavanja i prestanka rada
sistema. Rukovodilac programa i vlasnik sistema obezbeĊuju da se
sistem razvije i radi prema bezbednosnim zahtevima, dokumentovanim u
planu zaštite, a takoĊe i da korisnici sistema i specijalisti zaštite, dobiju
adekvatnu obuku o zaštiti. Rukovodilac programa i vlasnik sistema
koordiniraju C&A napore i obezbeĊuju potrebno osoblje i informacije za
sertifikatora/sertifikacioni tim. Rukovodilac programa i vlasnik sistema
treba da snose troškove sertifikacije i mogu pregledati sertifikacioni
izveštaj, pre dostavljanja DAA na akreditaciju.

Specijalista za zaštitu za sisteme koji su u upotrebi, odgovoran je za:

svakodnevnu bezbednost odreĊenih komponenti IKT sistema, ukljuĉujući
i fiziĉku i personalnu zaštitu, upravljanje incidentom, svest o potrebi
zaštite, obuku i obrazovanje, pomoć u razvoju politike zaštite i
neprekidnu usaglašenosti prakse i politike zaštite; identifikovanje sistema
za re-sertifikaciju ili re-akreditaciju, za koje još nije doneta odluka ili za
koje je promenjeno okruţenje, a za sistem u razvoju odgovoran je za
struĉno rukovoĊenje programom zaštite, [1].

- 625 -
Ostale uloge i odgovornosti u procesu C&A, kao što su predstavnik
korisnika, rukovodilac programa zaštite, operativni rukovodilac sistema i
tehniĉki rukovodilac sistema, mogu biti ukljuĉena u C&A proces.
Predstavnik korisnika, koji zastupa operativne interese korisnika u toku
celog ţivotnog ciklusa sistema, po potrebi pomaţe u C&A procesu i
uĉestvuje u nadzoru ispunjavanja bezbednosnih zahteva postavljenih u
planu zaštite. Rukovodilac programa zaštite, odgovoran je za primenu
standardnog C&A procesa, obezbeĊuje interna uputstva i politiku za
C&A proces, ili, ukoliko to odgovara, pregleda sertifikacione pakete, pre
dostavljanja DAA-u. Operativni rukovodilac sistema nadgleda da li
operativni rad i administracija zaštite IKT sistema obuhvataju
bekapovanje, obuku, odrţavanje kriptografskih kljuĉeva, administracija
korisnika i privilegija pristupa, kao i aţuriranje softvera za zaštitu.
Tehniĉki rukovodilac infrastrukture sistema nadgleda promene i
modifikacije i spreĉava da se ugrozi postojeći sistem zaštite, [1].

Neke uloge u C&A procesu mogu biti delegirane, kao diskreciono pravo
menadţera. Delegirana sa ovlašćenjem organizacije rade u definisanim
granicama na navedenim aktivnostima, a menadţer snosi odgovornost za
njihove rezultate i akcije. Ulogu i odgovornost DAA ne treba delegirati
izvoĊaĉima radova.

- 626 -
1.2. Bezbednosna kategorizacija IKT sistema za C&A

Generalno, IKT sistemi u sistemu e-Uprave mogu biti sistemi za:

glavne aplikacije ili opštu podršku. Svi IKT sistemi treba da budu
odobreni (akreditovani) za upotrebu.

Sistemi za glavne aplikacije izvršavaju jasno definisane funkcije za koje

postoje identifikovani bezbednosni zahtevi (npr. sistem za elektronske
finansijske transakcije). Glavna aplikacija moţe ukljuĉivati više
programskih, hardverskih i telekomunikacionih komponenti i moţe se
sastojati i od nekoliko manjih, posebnih aplikacija (npr. obraĉun plata, ili
kadrovska evidencija).

Sistemi za opštu podršku predstavljaju skup meĊusobno povezanih IKT

objekata, ili raĉunarskih okruţenja, koji rade pod istom kontrolom i dele
srodnu funkcionalnost i obezbeĊuju podršku za razliĉite korisnike i/ili
uobiĉajene aplikacije. Sistemi za opštu podršku moţe sadrţavati jednu ili
više glavnih aplikacija. Organizacija treba da obuĉi menadţere za
procenu aplikacija, koje se smatraju glavnim i da obezbedi da
bezbednosni zahtevi manje bitnih aplikacija budu obuhvaćeni zahtevima
za sistem za opštu podršku.

Povezani i distribuirani IKT sistemi su dva specijalna sluĉaja glavnih

aplikacija ili aplikacija sistema za opštu podršku i treba ih razmotriti pri
identifikaciji sistema za C&A. Povezani IKT sistemi odnose se na fiziĉki
i logiĉki mreţni pristup namenskim sistemima ili sistemima specijalne
namene (vojnim, za istraţivanja i razvoj naoruţanja i medicinskih
tehnologija, distribuciju elektriĉne energije i.t.d.). Distribuirani IKT
proces je opšti termin, koji se koristi da ukaţe na izmeštene poslovne
procese, informacione tehnologije ili informacione servise. U oba sluĉaja,
treba identifikovati pravila i zahteve za zaštitu i razmotriti ih u C&A
procesu.

- 627 -
1.3. Kategorije akreditacije

U odnosu na kategoriju IKT sistema za C&A, uobiĉajeno se

izdvajaju tri kategorije procesa akreditacije: 1) akreditacija sistema, 2)
tipska akreditacija i 3) lokacijska akreditacija. Organizacija treba da
izabere tip akreditacija koje najviše odgovara njenim potrebama.

Akreditacija sistema (Sl. 1.1) najĉešći je oblik akreditacije glavne

aplikacija ili sistema za opštu podršku na odreĊenoj lokaciji sa
specificiranim ograniĉenjima u odnosu na okruţenje sistema.
Sertifikacioni proces verifikuje sve bitne elemente upravljaĉkih,
operativnih i tehniĉkih kontrola za glavne aplikacije ili sistem za opštu
podršku, a rezultat je akreditacija rada na prihvatljivom nivou preostalog
rizika, [6], [8].

Sl. 1.1. Akreditacija sistema, [1]

Tipska akreditacija (Sl. 1.2.) izdaje se za sistem glavne aplikacije ili

opšte podrške, koji sadrţe uobiĉajeni skup hardvera, softvera i firmvera,
a distribuirani su na više lokacija u tipiĉnom radnom okruţenju. DAA
mora dati izjavu o preostalom riziku, jasnu definiciju radnog okruţenje,
identifikovati specifiĉno korišćenje sistema, ograniĉenja i procedure pod
kojim sistem moţe da radi. Znaĉajno se smanjuje vreme trajanja procene,
jer je lokalnoj organizaciji dostavljena poĉetna dokumentacija potrebna
za akreditaciju, ukljuĉujući i posebne procedure za bezbednost rada.
Osnovne bezbednosne testove i evaluaciju (ST&E), treba uraditi u centru
za testiranje i integraciju, ili na jednoj od predviĊenih radnih lokacija.
Instalaciju i konfigurisanje sistema zaštite treba testirati na svakoj radnoj
lokaciji u okviru lokalnog ST&E. Lokalno zaposleni su odgovorni za
nadzor usaglašenosti radnog okruţenja sa okruţenjem i odobrenom
konfiguracijom, koja je opisana u dokumentaciji o akreditaciji.

- 628 -
 Sl. 1.2. Tipska akreditacija, [1]

Lokalna akreditacija (Sl. 1.3) moţe se izdati sistemima glavne aplikacije

i/ili za opštu podršku koji se nalaze na istoj lokaciji u istom okruţenju i
sa jednakim faktorima rizika, a dele zajedniĉku strategiju i imaju
uporedive ranjivosti

Sl. 1.3. Lokalna akreditacija, [1]

- 629 -
1.4. Sertifikaciona i akreditaciona dokumentacija

Cilj C&A procesa je da obezbedi potrebne informacije, na osnovu

kojih DAA donosi obrazloţenu odluku, zasnovanu na proceni rizika, za
rad nekog IKT sistema u datom okruţenju. Svaki zadatak i aktivnost u
C&A procesu, paţljivo se planira. Sertifkacioni paket, kojeg priprema
sertifikator/sertifikacioni tim za DAA, obiĉno sadrţi:

1) plan zaštite (pregledan i dopunjen prema potrebama),

2) razvojni i/ili radni izveštaji ST&E,
3) završni izveštaj o proceni rizika i
4) izjavu sertifikatora.

Plan sistema zaštite ima centralnu ulogu u oblasti upravljanja rizikom,

C&A procesima i u dokumentovanju zaštite IKT sistema. Organizacija
koja ima kompletiran plan zaštite pre poĉetka C&A procesa, moţe ga
koristiti u pre-sertifikacionim aktivnostima, a koje nisu kompletirale plan
zaštite, mogu uzeti potrebne informacije iz plana za osnovne pre-
sertifikacione aktivnosti za odreĊeni C&A proces. Plan zaštite je
dinamiĉan dokument i ukoliko je izraĊen pre procene rizika, treba ga
dopuniti rezultatima procene rizika. DAA treba da ima diskreciono pravo
da u plan zaštite ukljuĉi dodatne informacije, [6].

Izveštaj procesa testiranja i evaluacije sistema zaštite (ST&E) osnovna

je komponenta C&A procesa. ST&E odreĊuje usklaĊenost IKT sistema
sa bezbednosnim zahtevima iz plana zaštite i verifikuje da li su u planu
identifikovane kontrole zaštite korektno i efikasno primenjene. ST&E se
moţe primeniti u procesu razvoja i procesu rada IKT sistema.

Razvojni ST&E proces primenjuje se za nove sisteme ili reinţenjering

sistema u fazi razvoja i akvizicije sistema. Izveštaji tipiĉno sadrţe
rezultate ispitivanja i procene hardvera, softvera i firmware, analize
arhitekture i funkcionalnog testiranja, a koriste se za verifikaciju
korektnosti implementacije, efikasnosti i efektivnosti tehniĉkih kontrola
zaštite u skladu sa primenjenim standardima. Više oslanja na detaljnu
projektnu dokumentaciju sistema, a vrši se za tipske akreditacije, kao
meĊukorak pre izvršavanja akreditacije na radnoj lokaciji.

Radni ST&E proces primenjuje se za nove ili modifikovane sisteme, po

isporuci i završetku instalacije u fazi implementacije, ili na postojećim

- 630 -
sistemima u fazi rada/odrţavanja. Izveštaj tipiĉno sadrţi rezultate
testiranja i evaluacije lokalnog IKT sistema, koji se odnose na
verifikaciju korektnosti implementacije, efikasnosti i efektivnosti
upravljaĉkih, operativnih i tehniĉkih kontrola zaštite i usklaĊenosti sa
bezbednosnim zahtevima. Moţe da ukljuĉi i funkcionalno testiranje,
testiranje na promene i analizu ranjivosti. Za reinţenjering sistema u
postupku C&A koriste se i razvojni i radni ST&E izveštaji.

Izveštaj o proceni rizika dokumentuje rezultate procene faktora rizika,

koja je osnova za procenu efikasnosti kontrola zaštite i donošenje odluke
o prihvatljivosti preostalog rizika. Za svaki preostali rizik, obrazlaţu se
prihvatanje ili odbijanje rizika i implementacija novih kontrola zaštite za
smanjenje rizika. Sertifikator procenjuje izveštaj procene rizika i
odreĊuje pouzdanost podataka. Izveštaj sertifikatora za DAA zasniva se
na informacijama iz izveštaja o proceni rizika i drugim dokumentima.
DAA koristi izveštaj o proceni rizika i druga dokumenta sertifikacionog
paketa, da bi doneo akreditacionu odluku.

Izveštaj sertifikatora daje pregled statusa bezbednosti sistema i dovodi u

vezu sve potrebne informacije za DAA, koji donosi odluku zasnovanu na
informacijama i proceni rizika. Izveštaj dokumentuje da su kontrole
zaštite korektno implementirane i da su efikasne u primeni. Izveštaj
takoĊe dokumentuje i kontrole zaštite koje nisu implementirane ili
primenjivane i predlaţe korektivne postupke.

- 631 -
2. UPRAVLJANJE PROCESOM SERTIFIKACIJE I
AKREDITACIJE

Kljuĉne faze procesa C&A sa pojedinaĉnim zadacima prikazane su

na Sl. 2.1. Primer opisa zadatka i podzadataka dat je u PRILOGU III
10A, [6].

Sl. 2.1. Faze i aktivnosti procesa sertifikacije i akreditacije, [1]

2.1. Faza pred-sertifikacije

Faza pred-sertifikacije je pripremna i sadrţi 6 zadataka:

 identifikacija sistema;
 inicijalizacija i odreĊivanje okvira;
 validacija plana zaštite;
 validacija inicijalne procene rizika;
 validacija i identifikacija kontrola zaštite i
 konaĉni dogovor (pregovaranje)
Koriste se brojne informacije iz tekućeg plana zaštite, procene rizika ili
druge relevantne dokumentacije. Ako nije kompletiran plan zaštite i
procene rizika, treba ih kompletirati pre prelaska na proces C&A. Ova
faza sadrţi opis svih zadataka i odgovarajućih podzadataka
predsertifikacije.

- 632 -
2.2. Faza sertifikacije
Namena ove faze je da kroz nezavisnu procenu, koristeći izabrane
tehnike i procedure verifikacije, pokaţe da su kontrole zaštite za dati IKT
sistem implementirane korektno i da su efikasne u praksi zaštite.
Korektna i efikasna implementacija kontrola zaštite neophodan je uslov
da bi se pokazala saglasnost sa bezbednosnim zahtevima. Plan faze
sertifikacije (Sl. 2.2) obuhvata 4 zadatka [4]: validaciju, verifikaciju,
ST&E i procenu rizika.

Plan sertifikacije

Testiranje i
Validacija Verifikacija Procena rizika
evaluacija (ST&E)

Izveštaj o sertifikaciji

Akreditaciona odluka

Sl. 2.2. Plan sertifikacije sistema zaštite, [1]

Razlike u odreĊenim procedurama verifikacije kontrola zaštite, izmeĊu

razvojnih i operativnih ST&E aktivnosti, tipiĉno su u koliĉini
raspoloţivih informacija. Za razvojni ST&E postoje brojne pretpostavke
u vezi okruţenja, u kojem će sistem raditi, a koje ne mogu biti potpuno
verifikovane sve dok se sistem ne pusti u rad. Sam proces sertifikacije
moţe se izvršiti u 5 razliĉitih koraka, [7]:

1. Revizija procene rizika: Preporuĉuje se da procena rizika bude u

skladu sa zahtevima, što nije neophodno. Primarni rezultat procene
rizika je da obezbedi listu prioritetnih mera zaštite.
2. Revizija dokumentacije politike zaštite: na bazi rezultata procene
rizika, treba da budu formulisane kontrole pristupa (AC), kontrole
zaštite, upravljanje vanrednim dogaĊajem i upravljanja incidentom.
3. Revizija projektne dokumentacije: dokumenta koja se zahtevaju za
sertfikaciju ukljuĉuju dijagrame mreţne kapije, logiĉki dijagram i

- 633 -
 dijagram infrastrukture sistema, koncept rada, listu obaveznih i
zahteva na bazi procene rizika i listu kritiĉnih konfiguracija.
4. Revizija planova i procedura: ukljuĉuje zadatke administracije
sistema zaštite, kontrolne zadatke testiranja proaktivne zaštite,
zadatke kontrole proaktivne zaštite i plan vanrednih dogaĊaja.
5. Revizija tekuće konfiguracije: ukljuĉuje proveru kritiĉnih komponenti
konfiguracije, kojom se verifikuje da li korišćeni alati ispunjavaju
zahteve i da li su iskoristivi.

Rezultati faze sertifikacije dokumentovani su u razvojnim i/ili

operativnim ST&E izveštajima u završnom sertifikacionom paketu, sa
planom zaštite i konaĉnim izveštajem o proceni rizika. Nakon
kompletiranja faze sertifikacije, izdaje se sertifikacioni paket sa
izveštajima, a C&A proces se nastavlja sa fazom akreditacije i donošenja
akreditacione odluke.

U PRILOGU III 10B prikazana je kompletna lista zadataka i

podzadataka u svim fazama procesa C&A. U PRILOGU III 10C
prikazan je skup pomoćnih tabela sistema merenja u fazama validacije i
evaluacije u procesu sertifikacije, koje sertifikator moţe koristiti u radu.

Osnovna namena procesa sertifikacije je da se odrede korektnost

implementacije i efektivnost kontrola zaštite IKT sistema u praksi zaštite.
Precizna i efikasna primena kontrola zaštite obezbeĊuje ispunjavanje
bezbednosnih zahteva. Postoji više tehnika za verifikaciju taĉnosti i
efikasnosti kontrola zaštite, koje se mogu primeniti u toku procesa C&A:

 intervjuisanje zaposlenih u organizaciji, koji imaju uloge u

bezbednosti IKT sistema;
 pregled i analiza politika zaštite, procedura, uputstava i druge
dokumentacije,
 nadzor operativnog rada i aktivnosti prakse zaštite,
 analiza testiranja sistemskog hardvera, softvera, firmware i operacija
i
 demonstracija ponašanja sistema zaštite, obuka i veţbe.

- 634 -
Definisana su tri bezbednosna nivoa sertifikacije (Security Level
Certification- SLC), [6]:

 SLC-1, početni nivo bezbednosne sertifikacije,

 SLC-2 srednji nivo bezbednosne sertifikacije i
 SLC-3 najviši nivo bezbednosne sertifikacija IKT sistema.

U PRILOGU III 10D opisani su glavni atributi nivoa sertifikacije i

prikazan je kratak pregled izbora nivoa sertifikacije. Svaki viši nivo
dodatno povećava intenzitet i rigoroznost primene tehnika verifikacije sa
prethodnog nivoa. Nivoe SLC detaljno opisuje Uputstvu za akreditaciju i
sertifikaciju, koje treba da bude sastavni deo dokumentacije zaštite.

U PRILOGU III 10E u Tabeli 1.1. sumirane su razne tehnike

verifikacije u odnosu na nivoe bezbednosne sertifikacije i prikazan je
primer verifikacije kontrola zaštite iz familije identifikacije i akreditacije
(I&A), [6], [8]. Praktiĉan sistem merenja procesa kontrole i verifikacije
nivoa zaštite IKT sistema na bazi ponderisanih odgovora na upitnik
(kontrolnu listu od 144 pitanja) i proraĉuna srednje aritimetiĉke vrednosti
odgovora, razvijen je u [5].

Za ilustrovanje procesa izrade plana sertifikacije i zadatka (podzadataka)

za sertifikaciju, razvijena je Vežba GIII P10A, sa zadatkom aţuriranja
procesa analize rizika.

Odnos izmeĎu nivoa sertifikacije i kontrola zaštite vaţno je razumeti.

Nivo sertifikacije i kontrole zaštite izabrane za IKT sistem, zasnovane su
na utvrĊenim nivoima zaštite poverljivosti, integriteta i raspoloţivosti
informacija. Nivo zaštite poverljivosti moţe uticati na inicijalni izbor
nivoa sertifikacije i kontrola zaštite. Standardni paket kontrola zaštite i
paket poboljšanih kontrola, koje izabere organizacija, obezbeĊuju
minimalne kontrole zaštite poverljivosti, integriteta i raspoloţivosti
informacija za niske, srednje, i visoke nivoe pretnji. Osnovni koncept je,
da se sa porastom nivoa rizika uvode dodatne kontrole zaštite po
diskrecionoj odluci organizacije, a proces sertifikacije postaje stroţiji i
povećava se intenzitet sertifikacije. Shodno tome dodaju se novi resursi
za sertifikaciju sistema za više nivoe pretnji i mnogo robusnije kontrole
zaštite.

- 635 -
2.3. Faza akreditacije

Faze akreditacije je namenjena da dovrši konaĉnu procenu rizika za

dati IKT sistem, aţurira plan zaštite, sumira rezultate sertifikacije i
donese odluku o akreditaciji. Konaĉna procena rizika zasniva se na
rezultatima ST&E iz faze sertifikacije. Sertifikacioni paket sadrţi sve
informacije koje DAA koristi da donese odluku o akreditaciji IKT
sistema. Faza akreditacije sadrţi 4 zadatka:

 konaĉna procena rizika,

 aţuriranje plana zaštite,
 zakljuĉci faze sertifikacije i
 odluka o akreditaciji.

Nakon kompletiranja procesa sertifikacije, sertifikacioni paket: finalni

plan zaštite, izveštaji procesa ST&E, finalni izveštaj o proceni rizika i
izveštaj sertifikatora, dostavljaju se DAA. Sertifikacioni proces je
završen je dokumentovan, a kontrole zaštite pravilno implementirane i
primenjene u skladu sa bezbednosnim zahtevima. Na osnovu ovih
informacije, DAA razmatra preostali rizik za sistem i odluĉuje da li da
autorizuje rad sistema i prihvati preostali rizik. Kada donosi konaĉnu
odluku, DAA moţe izdati: 1) potpunu akreditaciju, 2) delimičnu
(privremenu, uslovnu) akreditaciju i 3) odbijenu (ne prihvaćenu)
akreditacija, [6].

Potpuna akreditacija potvrĊuje da su bezbednosni zahtevi

zadovoljavajući, kontrole zaštite korektno implementirane, primenjivane
i efektivno rade. Sistem je ovlašćen za rad u okruţenju, navedenom u
planu zaštite, sa nekoliko restrikcija u procesiranju (ako ih ima). DAA
izdaje akreditaciono pismo sa dokumentacijom u prilogu koja potvrĊuje
akreditacionu odluku. Ova informacija je deo finalnog akreditacionog
paketa. Akreditaciona odluka koju daje DAA opisana je u završnom
akreditacionom paketu. Akreditacioni paket obiĉno sadrţi: 1)
akreditaciono pismo, 2) plan zaštite i 3) izveštaje koji dokumentuju
osnovu za akreditacionu odluku, u većini sluĉajeva izvedene iz
sertifikacionog paketa. Neke informacije iz plana zaštite, ST&E izveštaja
i izveštaja o proceni rizika, zbog osetljivosti mogu biti zabranjene za
publikovanje u finalnom akreditacionom paketu.

- 636 -
Delimična akreditacija potvrĊuje da trenutno nema usklaĊenosti sa svim
bezbednosnim zahtevima iz plana zaštite i svim neophodnim kontrolama
zaštite (nisu primenjene, ili ne rade efikasno). Potreba za radom sistema
je kritiĉna, pa se sistem pušta u rad, jer ne postoje druge mogućnosti. Da
bi se smanjio povećani rizik delimiĉna akreditacija je potvrda za
privremeni rad sistema u odreĊenom periodu i pod odreĊenim uslovima
do potpune akreditacije sistema, što se specificira u odluci DAA. Sve se
restrikcije paţljivo kontrolišu, a akreditacioni akcioni plan je razvijen
tako da omogućava:

 aktiviranje vitalnih kapaciteta za brzi oporavak i uspostavljanje rada

sistema,
 delimiĉnu akreditaciju samo za kritiĉne funkcije sistema,
 dostupnost resursa za kompletiranje akcionog plana i potrebnih
sertifikacionih zadataka,
 završetak akcionog plana u okviru dozvoljenog vremena koje
specificira DAA,
 smanjenje rizika do trenutno najniţeg mogućeg nivoa i
 prihvatljivost preostalog rizika.

DAA izdaje odgovarajuće akreditaciono pismo prema gornjim uslovima i

restrikcijama i podnosi dodatnu dokumentaciju, ako je neophodno.
Tipske akreditacije mogu se smatrati delimiĉnim akreditacijama, sve dok
se ne izvrši operativna ST&E, ne zadovolje odgovarajući lokalni
bezbednosni zahtevi i dok se odgovarajuće lokalne kontrole zaštite
pravilno i efikasno ne implementiraju i primenjuju. Kada se jednom izda
delimiĉna akreditacija, DAA na operativnoj i radnoj lokaciji prihvata
odgovornosti za bezbednost sistema i informacija.

Odbijena akreditacija potvrĊuje da sistem ne odgovara bezbednosnim

zahtevima i kontrolama zaštite, kao što je navedeno u planu zaštite;
preostali rizik je takoĊe neprihvatljivo visok, a aktivnosti sistema nisu
kritiĉne za trenutne potrebe radne organizacije. Sistem u razvoju nije
ovlašćen za dalji razvoj, a sistem u radu se zaustavlja. DAA izdaje
odgovarajuće akreditaciono pismo o neprihvatanju rezultata sertifikacije,
ukljuĉujući dodatnu dokumentaciju koja potvrĊuje odluku o odbijanju
izdavanja akreditacije.

- 637 -
Primeri uzoraka teksta odluka o potpunoj, delimiĉnoj i uskraćenoj
akreditaciji i izveštaja sertifikatora dati su u PRILOGU III 10F. U
PRILOGU III 10G dat je primer aktivnosti pripreme sporazuma za
izvršavanje procesa C&A sa zadacima, ulazima i izlazima, [6].

Za akreditacija velikih i kompleksnih sistema postavljanje granica

procesa C&A najveći je izazov za organizacije. Problem se rešava
dekomponovanjem sloţenog sistema i C&A tih komponenti. Akreditacija
sloţenog sistema moţe da sadrţi jednu ili više komponenti podsistema,
sertifikovanih na odgovarajućem nivou, baziranom na dokumentovanom
nivou zaštite i kontrolama zaštite. Sertifikacioni paket je modifikovan
tako da ukljuĉuje po jedan ST&E izveštaj za svaku komponentu
podsistema, zajedno sa finalnim izveštajem o proceni rizika koji se
odnosi na opšti rizik celine sloţenog sistema

2.4. Faza post-akreditacije

Namena ove faze je da se nadzire status datog IKT sistema, kako bi se

utvrdilo da li ima znaĉajnih izmena u konfiguraciji sistema, ili znaĉajnih
izmena u okruţenju, koje mogu imati uticaje na poverljivost, integritet i
raspoloţivost informacija. Aktivnost nadzora je neophodna, da bi se
odrţao prihvatljiv nivo preostalog rizika. Kada su promene sistema ili
okruţenja znaĉajne u odnosu na zaštitu sistema, poĉinju aktivnosti za
reakreditaciju. Faza postakreditacije ima tri zadatka:

- aţuriranje procene rizika,

- aţuriranje opisa sistema i okruţenja,
- reakreditacija i odlaganje sistema.

Faza postakreditacije je kontinualan proces, koji je neophodan, da bi se

ukazalo na dinamiĉku prirodu misije organizacije i na brze promene
tehnologije korišćene za podršku te misije u organizaciji. Uputstvo za
izradu procedure za planiranje i izvršavanje procesa sertifikacije i
akreditacije dato je u PRILOGU III 10H, [1].

- 638 -
3. REZIME

Sertifikacija je a postupak tehniĉke i netehniĉke evaluacije kontrola

zaštite IKT sistema, koji obezbeĊuje neophodne informacije
(sertifikacioni paket) za proces akreditacije. Akreditacija je proces auto-
rizacije ili ovlašćenja sistema za rad na prihvatljivom nivou rizika, posle
glavne modifikacije ili razvoja novog IKT sistema, a obavlja je
imenovani entitet/lice, kroz kvalitativnu verifikaciju upravljaĉkih,
operativnih i tehniĉkih kontrola zaštite. Akreditacija utvrĊuje stepen na
kome se odreĊenim procesom projektovanja i implementacije kontrola
zaštite postiţe skup specificiranih bezbednosnih zahteva. Akreditacijom
sistema, menadţment prihvata rizik pridruţen tom sistemu.

Metodologija razvoja procesa C&A obuhvata definisanje uloga i

odgovornosti (entitet za akreditaciju, sertifikator/tim za sertifikaciju,
specijalista za zaštitu, vlasnik sistema i druge); identifikovanje IKT
sistema za C&A (za glavnu aplikaciju ili opštu podršku), izbor kategorije
akreditacije (sistema, tipska ili lokacijska akreditacija), upravljanje
procesom C&A i izrada dokumentacije. Osnovna namena procesa
sertifikacije je da se odredi da li su kontrole zaštite nekog IKT sistema
korektno implementirane i efektivne u praksi zaštite. Definisana su tri
bezbednosna nivoa sertifikacije (Security Level Certification- SLC):
nizak-SLC-1, srednji- SLC-2 i visok-SLC-3.

Sertifkacioni paket je konaĉni skup dokumenata, koje priprema

sertifikator i sertifikacioni tim za autoritet akreditacije, a obiĉno sadrţi:
plan zaštite, razvojni i/ili radni izveštaji o testiranju i evaluaciji sistema
zaštite (ST&E), završni izveštaj o proceni rizika i izjavu sertifikatora. Na
osnovu ovih dokumenata autoritet akreditacije donosi odluku o: potpunoj
akreditaciji, delimičnoj (privremenoj) akreditaciji i odbijanju
(neprihvatanju) akreditacije.

Akreditacioni paket potpune akreditacije obiĉno sadrţi: akreditaciono

pismo, plan zaštite i sertifikacione izveštaje koji dokumentuju osnovu za
akreditacionu odluku. Delimiĉna akreditacija ili potvrda za osnovnu
primenu sistema, privremena je potvrda koja moţe biti izdata za rad
sistema u odreĊenom periodu i pod odreĊenim uslovima do potpune
akreditacije sistema, što se specificira u odluci entiteta za akreditaciju.
Ako sistem ne odgovara bezbednosnim zahtevima i kontrolama zaštite,
navedenim u planu zaštite, preostali rizik je neprihvatljivo visok, a

- 639 -
aktivnosti sistema nisu kritiĉne za trenutne potrebe rada organizacije,
entitet za akreditaciju odbija izdavanje akreditacije.

Akreditacija velikih i kompleksnih sistema rešava se definisanjem

granica procesa C&A, dekomponovanjem sloţenog sistema i C&A tih
komponenti.

Proces C&A sadrţi faze: predsertifikacije, sertifikacije, akreditacije i

postakreditacije. Faza pred-sertifikacije je priprema i sadrţi 6 zadataka:
identifikacija sistema, inicijalizacija i odreĊivanje okvira, validacija plana
zaštite, validacija inicijalne procene rizika, validacija i identifikacija
kontrola zaštite i konaĉni sporazumi (za naĉin sertifikacije sistema). Faza
sertifikacije verifikuje kroz nezavisnu procenu, koristeći izabrane tehnike
i procedure verifikacije, da su kontrole zaštite implementirane korektno i
efikasne u praksi zaštite. Rezultati sertifikacije su dokumentovani u
razvojnim i/ili operativnim ST&E izveštajima, koji su ukljuĉeni u završni
paket sertifikacije zajedno sa planom zaštite i konaĉnim izveštajem o
proceni rizika. Faza sertifikacije obuhvata 2 zadatka: doterivanje
procedure verifikacije i testiranje i procena kontrola zaštite (ST&E), a
moţe se izvršiti u 5 koraka: procene rizika, revizija politike, projektne
dokumentacije i plana i procedura zaštite. Faza akreditacije sadrţi 4
zadatka: konaĉna procena rizika, aţuriranje plana zaštite, zakljuĉci
sertifikacije i odluka o akreditaciji. Faza postakreditacije monitoriše
status datog IKT sistema, kako bi se utvrdilo da li ima izmena u
konfiguraciji sistema i okruţenju, koje mogu uticati na poverljivost,
integritet ili raspoloţivost informacija. Faza postakreditacije ima tri
zadatka: aţuriranje procene rizika, aţuriranje stanja sistema i okruţenja,
reakreditacija i odlaganje sistema.

- 640 -
4. KLJUĈNI TERMINI

Akreditacija (Accreditation) – Zvaniĉna odluka upravne strukture, koju donosi

zvaniĉno lice ili organ, da ovlašćuje rad nekog IKT sistema i da eksplicitno
prihvata rizik za poslove organizacije (ukljuĉujući misiju, funkcije,
reputaciju ili ugled), imovinu organizacije ili pojedince, na bazi prihvaćene
implementacije kontrola zaštite.
Akreditacioni paket (Accreditation Package) – Dokazi, obezbeĊeni za
zvaniĉno lice, koji se koriste u procesu donošenja bezbednosne akreditacione
odluke. Dokazi ukljuĉuju, ali nisu ograniĉeni na: (i) plan zaštite sistema, (ii)
rezultate procene iz procesa sertifikacije i (iii) plan akcije i taĉke kontrole.
Autoritet za akreditaciju (Accrediting Authority): entitet/zvaniĉno lice sa
ovlašćenjem da formalno preuzme odgovornost za rad IKT sistema na
prihvatljivom nivou rizika za poslove organizacije (ukljuĉujući misiju,
funkcije, reputaciju ili ugled), imovinu organizacije ili pojedince.
Glavna aplikacija (Major Application) – Neka aplikacija koja zahteva
specijalnu zaštitu zbog rizika i veliĉine štete od gubitaka, zloupotreba, ili
neovlašćenog pristupa, ili modifikacije informacija i aplikacije.
Granice akreditacije (Accreditation Boundary)- Sve komponente IKT sistema
koje treba akreditovati, iskljuĉujući odvojeno akreditovane sisteme , na koje je
sistem povezan.
Sertifikacija (Certification) – Sveobuhvatna procena upravljaĉkih, operativnih i
tehniĉkih kontrola u IKT sistemu, koja se izvršava kao podrška procesa
akreditacije, a odreĊuje u kojem obimu su kontrole implementirane korektno,
rade kako je planirano i daju ţeljene rezultate u odnosu na bezbednosne zahteve
za sistem.
Sistem za opštu podršku (General Support System) – Skup meĊusobno
povezanih informacionih objekata pod istom direktnom upravljaĉkom
kontrolom, koji imaju zajedniĉke funkcionalnosti. Normalno ukljuĉuje hardver,
softver, informacije, aplikacije, podatke, komunikacije i ljude.

- 641 -
5. LITERATURA

1. Milosavljević M., Veinović M., Grubor G., Savić Z., Studija

razvoja programa zaštite u sistemu e-Uprave, RZII. decembar,
2005.
2. National Computer Security Center, A guide to understanding
security testing and test documentation in trusted systems, NCSC-
TG-023, V. 1, www.ncsc.gov, 1994.
3. National Computer Security Center, Certification and
Accreditation Process Handbook for Certifiers, NCSC-TG-031,
Version 1, July 1996.
4. Naval Research Laboratory, USA, Handbook for the Computer
Security Certification of Trusted Systems,
http://www.itd.nrl.navy.mil/ITD/5540/publications/handbook,
1995.
5. Rodić B., ĐoreĊević G., Da li ste sigurni da ste bezbedni,
Produktivnost AD Beograd, 2004.
6. Ross R., Swanson M. Guidelines for the Security Certification
and Accreditation of Federal Information Technology Systems,
―NIST SP 800-37, http://csrc.nist.gov/ publications /drafts/sp800-
37-Draftver2.pdf, 2004.
7. UK IT Security Evaluation & Certification Scheme Certification
Body, UK IT Security Evaluation and Certification Scheme,
www.uk.it.secscb.com, V. 3.0, 1996.
8. Zadjura J., An Introduction to Certification and Accreditation,
SANS Institute, V. 1.4, 2003.

- 642 -