Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema BEZBEDNOST RAUNARSKIH SISTEMA Zavod za Informatiku i Internet 1

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Sadraj Sadraj........................................................................... ............................................................ 2 Slike ........... ................................................................................ ............................................... 4 Tabele........................ ................................................................................ ................................ 5 Kratak sadraj ................................ ................................................................................ ........... 6 Glava 1 .......................................................... ............................................................................ 7 U VOD ............................................................................ ........................................................... 7 1.1 Uvod.......... ................................................................................ ................................ 8 1.2 Namena .................................. ................................................................................ ... 9 1.3 ivotni ciklus razvoja sistema ......................................... ....................................... 10 1.4 Programi evaluacije komponenti pr oizvoda ........................................................... 10 1.5 Odnos prema drugim NIST publikacijama ............................................... .............. 11 1.6 Organizacija specijalnih publikacija ..................... .................................................. 12 Glava 2 .................. ................................................................................ .................................. 14 OSNOVE C&A PROCESA........................ ............................................................................ 14 2.1 Uloge i odgovornosti........................................................ ....................................... 14 2.1.1 IMENOVANI AUTORITET ZA ODOBRAVA NJE (DAA)............................. 14 2.1.2 SERTIFIKATOR I SERTIFIKACIONI TI M................................................. 15 2.1.3 RUKOVODILAC PROGRAMA I VLASNIK SISTEMA ............................ 15 2.1.4 INOVNIK ZA BEZBEDNOST SI STEMA ................................................. 16 2.1.5 DRUGE ULOGE I N JIHOVO DODELJIVANJE U PROCESU C&A......... 16 2.2 IT sistemi ................... ................................................................................ ............. 17 2.2 1 GLAVNE APLIKACIJE ....................................... ......................................... 17 2.2 2 SISTEMI ZA OPTU PODRKU ........ ......................................................... 18 2.2 3 BAZA IT MEUPOV EZIVANJA I IZMETENI IT PROCESI .................. 18 2.3 Katagorije akreditacije ................................................................................ ............. 18 2.3 1 SISTEMI AKREDITACIJA .................................... ....................................... 19 2.3 2 TIP AKREDITACIJE .............. ....................................................................... 19 2.3 3 LOKALNA AKREDITACIJA .......................................................... ............. 21 2.4 Sertifikaciona i akrediticiona dokumentacija............... ............................................. 21 2.4 1 PLAN SISTEMA BEZBEDNOSTI. ............................................................... 22 2.4 2 IZVETAJI TESTA BEZBEDNOSTI I PROCENE...................................... 22 2.4 3 IZVET AJ PROCENE RIZIKA............................................................... ...... 23 2.4 4 IZVETAJ SERTIFIKATORA ........................................... ........................... 23 2.5 Akreditacija velikih i kompleksnih sistema... ........................................................... 23 2.6 Akreditacione odluke i preostali rizik....................................................... ................ 25 2.6.1 POTPUNA AKREDITACIJA ................................. ....................................... 26 2.6.2 DELIMINA AKREDITACIJA .......... .......................................................... 26 2.6.3 NEPRIHVAENA A KREDITACIJA............................................................ 27 Glava 3 ............................................................................. ....................................................... 28 KONTROLA BEZBEDNOSTI

I NIVOI SERTIFIKACIJE .................................................. 28 3.1 Karakterizacija sistema informacione tehnologije................................ ................... 28 3.1.1 KRITINOST/OSETLJIVOST SISTEMA....................... .............................. 28 3.1.2 IZLOENOST SISTEMA ....................... ........................................................ 29 3.1.3 NIVO BEZBEDNOS TI ............................................................................. ...... 29 2

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 3.1.3.1 Spoljna izloenost sistema................................................ ................... 31 3.1.3.2 Unutranja izloenost sistema........................ ..................................... 32 3.2 Kontrole sigurnosti................ ................................................................................ .. 33 3.2.2. IZBOR KONTROLA BEZBEDNOSTI ........................................ ................. 35 3.2.3 PODEAVANJE IZBORA KONTROLA SIGURNOSTI................. ............ 36 3.2.4 KRATAK PREGLED IZBORA KONTROLA SIGURNOSTI ................ ..... 37 3.3 Nivoi sertifikacije sigurnosti..................................... .............................................. 37 3.3.1 SERTIFIKACIJA SIGURNOSTI NIVO 1 (SCL-1)....................................... 38 3.3.2 SERTIFIKACIJA SI GURNOSTI NIVO 2 (SCL-2)....................................... 38 3.3.3 SERTIFIK ACIJA SIGURNOSTI NIVO 3 (SCL-3)....................................... 39 3.3.4 IZBOR NIVOA SERTIFIKACIJE ...................................................... ........... 40 3.3.5 KRATAK PREGLED IZBORA NIVOA SERTIFIKACIJE.................. ........ 41 3.3.6 ODNOS KONTROLE SIGURBOSTI / NIVO SERTIFIKACIJE ............... .. 43 3.4 Verifikacija kontrola sigurnosti ..................................... ......................................... 43 Glava 4 ........................... ................................................................................ ......................... 46 PROCES SERTIFIKACIJE I AKREDITACIJE ............... ..................................................... 46 4.1 Faza pred-sertifika cije............................................................................ ................. 47 4.2 Faza sertifikacije .................................... ................................................................. 58 4.3 Faza ak reditacije ..................................................................... ................................ 60 4.4 Faza post-akreditacije ................. ............................................................................ 64 3

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Slike Slika 2.1 Kljuni uesnici C&A procesa ............................................. ................................... 17 Slika 2.2 Sistem akreditacije............ ................................................................................ ....... 19 Slika 2.3 Tip akreditacije .......................................... .............................................................. 20 Slika 2.4 Loka lne akreditacije................................................................ ................................. 21 Slika 2.5 Primer dekomponovanja sistema.... ......................................................................... 25 Sli ka 3.1 Konvencije imenovanja za kontrole sigurnosti............................. ........................... 35 Slika 3.2 Izbor kontrola sigurnosti.............. ............................................................................ 36 Slika 4.1 Faze i aktivnosti procesa sertifikacije i akreditacije ............... ................................. 46 4

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Tabele Tabela 3.1 NIVOI BRIGE ZA KRITINOST / OSETLJIVOST SISTEMA ....................... . 30 Tabela 3.2 NIVOI BRIGE ZA SPOLJNJU IZLOENOST................................ ................... 32 Tabela 3.3 NIVOI BRIGE ZA UNUTRANJU IZLOENOST ............. .............................. 33 Tabela 3.4 NIVOI SERTIFIKACIJE I TEHNIKE VERIF IKACIJE...................................... 39 Tabela 3.5 ODREIVANJE TOTALNE IZ LOENOSTI SISTEMA................................... 40 Tabela 3.6 KONTROLE SIGURN OSTI I PROCEDURE VERIFIKACIJA ......................... 44 5

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Kratak sadraj Cirkularno pismo A-130, Upravljanje saveznim informatikim resursima, poslato iz k ancelarije za upravljanje i budet (OMB), zahteva da savezne agencije planiraju si gurnost i obezbede da odgovarajui slubenici dobiju odgovornost za sigurnost sistem a, kao i ingerenciju da autorizuju sistem pre nego to se sistem pusti u eksploata ciju, a zatim da se ovaj postupak primenjuje periodino. Ova autorizacija, koju sp rovode visoki slubenici agencije, se ponekad zove i akreditacija. Pod sertifikaci jom se podrazumeva postupak tehnike i netehnike evaluacija jednog IT sistema, koji obezbeuje neophodne informacije, koje zahtevaju autorizovani slubenici, da bi se donela valjana odluka zasnovana na proceni rizika, da li sistem treba pustiti u rad. Ova specijalna publikacija uspostavlja standardni proces, opte zadatke, i sp ecifine podzadatke, da bi se sertifikovao i akreditovao IT sistem koji podrava rad izvrnog dela savezne vlade. Ona obezbeuje novi pristup serktifiakciji i akreditac iji (C&A), koji koristi standardizovan proces, da bi se verifikovala korektnost i efikasnost sigurnosnih mehanizama koje ima jedan IT sistem, kako bi se odravala odgovarajua sigurnost sistema. Korienje standarda, minimalnih kontrola sigurnosti, poverljivosti razliitih nivoa (niskih, srednjih, i visokih), integriteta i raspo loivosti (definisano u NIST publikaciji 800-53) 1kao i upotreba standardizovanih tehnika i procedura verifikacije (NIST publikacija 800-53A)2 podstie: Sertifikaci ju IT sistem sa veim stepenom konzistetnosti, uporedljivosti, i ponavljajue sertif ikacije Potpunije, pouzdanije informacije za autorizovane slubenike koje omoguavaj u bolje razumevanja sloenih IT sistema, pridruenih rizika i njihove osetljivosti O dluke ovlaenih slubenika procesa akreditacije, zasnovane na vie informacija Dok se C &A proces fokusira na savezne sisteme za obradu, uvanje i prenos osetljivih (nekl asifikovanih) informacija, odgovarajui zadaci i podzadaci, kontrola sigurnosti i tehnike i procedure verifikacije su iroko definisane tako da mogu biti univerzaln o primenljive za sve tipove IT sistema, ukljuujui sisteme koji se koriste za nacio nalnu bezbednost ili obavetajne sisteme, ukoliko se to zahteva od strane odgovara juih organa vlasti. Moda e u ovom dokumentu biti povremenog pozivanja na sisteme na cionalne bezbednosti, ali samo u svrhe tehnike konzistencije i kompletnosti razvo ja standardnog C&A procesa za savezne IT sisteme, i ne treba ih interpretirati k ao uputstvo NIST-a svojim agencijama za ispunjavanje zakonskih odgovornosti po Z akonu o Bezbednosti raunarskih sistema, 1987. Dravne, lokalne i plemenske vlade i organizacije privatnog sektora, ukljuujui kritinu infrastrukturu SAD, se ohrabruju da razmotre korienje uputstava obezbeenih u odgovarajuoj, specijalnoj publikaciji. O va specijalna publikacija zamenjuje NIST savezne standarde za obradu podataka (F IPS) Publikacija 102, Uputstvo za sertifikaciju i akreditaciju bezbednosti raunar skih sistema, Septembar 1983. Specijalna Publikacija 800-53, Minimum kontrola bezbednosti za savezne sisteme i nformacionih tehnologija, se razvija i NIST e je objaviti na javnu diskusiju u pr olee 2003. Specijalna Publikacija 800-53A, Tehnike i procedure verifikacije kontr ola bezbednosti u Saveznim sistemima za informacione tehnologije, se razvija i N IST e je objaviti na javnu diskusiju u prolee 2003 2 1 6

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Glava 1 UVOD POTREBA ZA SERTIFIKACIJOM I AKREDITACIJOM Poverenje u sigurnost informacionih te hnologija moe se postii kroz preduzete akcije za vreme procesa razvoja, evaluacije i rada... Informacione tehnologije (IT)3 predstavljaju pogon savremenih preduzea , kako u javnom tako i u privatnom sektoru. Vladine agencije i preduzea se sve vie oslanjaju na IT sisteme da bi obavile vane zadatke i funkcije i poveale produktiv nost preduzea. Tokom poslednje dekade, ovi sistemi su postali izuzetno moni, a nji hove karakteristike i odgovarajue proirene mogunosti eksponencijalno rastu u vremen u. Poveana funkcionalnost i proirene mogunosti IT, su dramatino poveali sloenost siste ma, to se naroito odnosi, na veinu kritine informacione infrastrukture. Sloenost je g lavna briga, kada se procenjuje sigurnost jednog IT sistema, jer to je sistem kom pleksniji to je tee temeljno pregledati sve njegove komponente. IT bezbednost ukl juuje operacije koje tite i uvaju informacije i sisteme, obezbeujui njihovu poverljiv ost, integritet i raspoloivost. Ovo ukljuuje i obezbeenje neprekidnog rada sistema sa ugraenim procedurama sigurnosti, otkrivanja i reakcije samog sistema. Osnovna odgovornost upravljanja jednim sistemom je obezbeenje razvoja odgovarajuih ciljeva sigurnosti i identifikacija rizika bezbednosti, kao i njihov balans u odnosu na operativne zahteve. Cirkularno pismo A-130, Upravljanje saveznim informatikim re sursima, poslato iz kancelarije za upravljanje i budet (OMB), zahteva da savezne agencije planiraju bezbednost i obezbede da odgovarajuim slubenicima bude dodeljen a odgovornost za bezbednost, kao i da autorizuju sistem pre nego to pone operacion alan rad sistema, a zatim da se ovaj postupak primenjuje periodino. Ove odgovorno sti upravljanja predpostavljaju da odgovorni agencijski slubenici razumeju rizike i druge faktore koji mogu negativno uticati na ciljeve zadatka bezbednosti. I v ie od toga, ovi slubenici moraju razumeti tekui status programa bezbednosti i uprav ljanja, da bi mogli valjano prosuivati i donositi odluke o investicijama, kako bi se mogui rizik sveo na prihvatljiv nivo. Cilj agencijskih slubenika je da obave s voj posao, kao i da obezbede ono to se u OMB cirkularnom pismu A-130 definie kao a dekvatna bezbednost, ili srazmerna sigurnost u odnosu na mogui rizik i veliinu tete , koja je nastala kao rezultat gubitka, pogrenog korienja ili neautorizovanog prist upa informacijama ili njihovoj modifikaciji. Ova definicija eksplicitno daje nag lasak na korienje politike sigurnosti sa efikasnim trokovima, zasnovane na proceni rizika , kao to je to ustanovio Javni Zakon 110-235 (Zakon o Bezbednosti raunarski h sistema iz 1987). Jedan IT sistem je skup informatikih resursa agencije, organizovan za sakuplja, s meta, obrauje, odrava, koristi, deli, iri, raspolae, prikazuje ili prenosi informacij e. Kategorije sistema su Glavne aplikacije i Opte eme podrke, koje obuhvataju platf orme IT povezivanja i spoljne IT procese. U Glavi dva je dat detaljniji opis ovi h kategorija sistema. 3 7

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema

Autorizacija jednog IT sistema, koji moe da procesira, smeta ili prenosi informaci je, dodeljuje se od strane ovlaenog slubenika, je forma koja obezbeuje kvalitetnu ko ntrolu i istovremeno je izazov rukovodiocima i tehnikom kadru da nau najbolje meru sigurnosti, u datim ogranienjima: tehnike prirode, koji proizilaye iz operativnog rada kao i glavnih zahteva zadatka. Neke agencije se na ovo referiu kao na akred itaciju. Akreditacija, koja se zahteva OMB cirkularnim pismom A-130, treba da bu de zasnovana na proceni rukovodstva, kontroli rada, kao i tehnikoj kontroli koja je pridruena jednom IT sistemu. Poto plan bezbednosti 4, pripremljen od strane age ncije, dokumentuje zatitu zahteva i sigurnosne kontrole IT sistema, plan je osnov ni dokument koji se zahteva u procesu akreditacije (na taj nain se smanjuje nepot rebna administracija) dopunjen specifinim studijama, ako je potrebno. Uz plan bez bednosti, za akreditaciju je potrebno napraviti i procenu rizika kao i evaluacij u sigurnosti. Procena rizika je opisana u specijalnoj publikaciji 800-30, Vodi za upravljanje rizikom sistema informacionih tehnologija, koju je izdao Nacionalni Institut za Standarde i Tehnologiju. (NIST).U postupku procene rizika se identi fikuju mogue pretnje sistemu i procenjuje njegova ranjivost, procenjuju se planir ane i postojee kontrole bezbednosti, odreuje se verovatnoa da se dogodi odreeno ranj avanje sistema i sprovodi analiza posledica takvih uticaja. Pre poetka akreditaci je, treba zapoeti inicijalnu analizu rizika IT sistema. Rezultati ove poetne anali ze e se koristiti za vreme procenjivanja bezbednosti, a ak moda i ponovo pregledati i ispraviti po proceni analize rizika. Sertifikacija je proces koji obuhvata pr ocenu tehnikih i ne-tehnikih kontrola bezbednosti IT sistema, da bi se podrao proce s akreditiacije i ustanovio stepen na kome se odreenim projektovanjem i implement acijom postie skup specificiranih zahteva bezbednosti. Postupak sertifikacije obe zbeuje potrebne informacije rukovodstvu da formalno izjave da je odobreno putanje jednog IT sistema u rad, sa prihvatljivim nivoom rizika. Ova odluka se zasniva n a implementaciji dogovorenog skupa upravljakih, radnih i tehnikih kontrola. Akredi tacijom sistema zvaninici prihvataju rizik pridruen tom sistemu. Formalizacija pos tupka akreditacije smanjuje mogunost da sistem bude puten u rad, bez odgovarajue ko ntrole rukovodstva. Reakreditaciju treba uraditi pre znaajnih promena, ali najman je svake tree godine. Ovo je potrebno raditi ee kada je u pitanju vei rizik i vea mogu ost nastanka tete. 1.1 Uvod Znaajan procenat saveznih IT sistema na podruju kritine infrastrukture jo uvek nije kompletirao potrebnu sertifikaciju bezbednosti, i zato su doveden u rizian poloaj osetljive vladine informacije i programi, sa potencijalnim uticajem na nacionaln u i ekonomsku bezbednost. Sertifikati bezbednosti, daju slubenicima agencije potr ebne informacije za izdavanje dozvolu za siguran rad ovih IT sistema. Postoji ve liki broj procedura za sertifikaciju bezbednosti u okviru savezne vlade, koje su sloenije nego to bi to trebalo, zastarele i skupe za implementaciju to za rezultat ima procenu, da su one nekonsistentne, sa grekama i ne mogu se ponavljati ni na kom stepenu pouzdanosti. Takoe, postoji nedostatak kompetentne ekspertize bezbedn osti, koja je neophodna za uvoenje sertifikacije bezbednosti za ogroman broj 4 Dovretak plana bezbednosti IT sistema je zahtev OMB cirkulara A'130 i Zakona o Be ybednosti raunarskih sistema iz 1987. NIST specijalna publikacija 800-18 daje upu tstvo za preporueni format i sadraj planova sistema sigurnosti. 8

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema saveznih IT sistema. Zato je NIST inicirao projekat visokog prioriteta Marta 200 2 da bi se obavili sledei zadaci: Razvoj standardnih uputstava i procedura za ser tifikaciju i akreditaciju saveznih IT sistema, ukljuujui kritinu infrastrukturu SAD . Definisanje osnovnih minimalnih kontrola bezbednosti za savezne IT sisteme. Po dsticanje razvoja organizacija za procenu u javnom i privatnom sektoru, kao i se rtifikaciju pojedinaca sposobnih da obezbede isplativu sertifikaciju bezbednosti visokog kvaliteta. na osnovu standardnih uputstava i procedura Posebne koristi inicijative za sertifikaciju i akreditaciju (C&A) su Sertifikacija IT sistema sa veim stepenom konsistetnosti, uporedljivosti i mogunosti za ponovnu sertifikaciju Potpunije, pouzdanije informacije za ovlaene slubenike to ima za posledicu bolje ra zumevanja sloenih IT sistema, njima pridruenih rizika i njihove osetljivosti i zat o bolje obrazloenih odluka zvaninika Vea raspoloivost usluge kompetentne evaluacije i procene bezbednosti Bezbedniji IT sistemi u okviru savezne vlade. 1.2 Namena Namena ove specijalne publikacije je da uspostavi standardan proces, opte zadatke i specifine podzadatke da sertifikuje i akredituje IT sisteme, koji se koriste u vrenju izvrne vlasti savezne vlade. Dok se C&A proces fokusira na savezne sisteme za obradu, uvanje i prenos osetljivih (neklasifikovanih) informacija, odgovarajui zadaci i podzadaci, kontrola bezbednosti i tehnike i procedure verifikacije su i roko definisane, tako da mogu biti univerzalno primenljive za sve tipove IT sist ema, ukljuujui nacionalnu bezbednost ili obavetajne sisteme, ukoliko se to zahteva od strane odgovarajuih vlasti. Moda e u ovom dokumentu biti povremenog pozivanja na sisteme nacionalne bezbednosti5. Ove reference imaju namenu samo da se obezbedi tehnike konzistencija i kompletnost razvoja standardnog C&A procesa za federalne IT sisteme, i nikako ih ne treba intertrepirati kao uputstvo NIST-a svojim agen cijama za ispunjavanje zakonskih odgovornosti po Zakonu o Bezbednosti raunarskih sistema iz 1987. Ohrabruju se dravne, lokalne i plemenske vlade i organizacije pr ivatnog sektora, ukljuujui SAD kritinu infrastrukturu, da razmotre korienje uputstava obezbeenih u odgovarajuoj, specijalnoj publikaciji. Ova specijalna publikacija za menjuje NIST savezne standarde za obradu podataka (FIPS) Publikacija 102, Uputst vo za sertifikaciju i akreditaciju bezbednosti raunarskih sistema, Septembar 1983 . Nacionalni sistemi za bezbednost su oni IT sistemi koji rade za vladu SAD, njene ugovarae ili agente, koji sadre klasifikovane informacije ili kao to je dalje izloe no u 10 U.S.C. sekcija 23-15, koja obuhvata: obavetajne aktivnosti ili kriptograf ske aktivnosti koje se odnose na nacionalnu bezbednost, komandovanje i kontrolu vojnih snaga, opremu koja je integralni deo oruja i oruanih sistema, ili opremu ko ja je kritina za direktno ispunjavanje vojnih ili obavetajnih misija. 5 9

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 1.3 ivotni ciklus razvoja sistema Postoje mnogi tipovi saveznih IT sistema koji zahtevaju C&A ukljuujui i stare sist eme, novo razvijene sisteme, kao i sisteme koji su podvrgnuti veim ili manjim mod ifikacijama ili auriranju. Ovi sistemi se mogu okarakterisati fazom ivotnog ciklus a sistema u kojoj se oni trenutno nalaze. Tipino, postoji pet faza koji definiu ivo tni ciklus sistema: (1) inicijalizacija, (2) razvoj/akvizicija, (3) implementaci ja, (4) rad/odravanje, (5) prestanak rada sistema. Elementi standardnog C&A proce sa definisani u ovoj specijalnoj publikaciji mogu se primeniti na ma koji sistem , u ma kojoj fazi njegovog ivotnog ciklusa. Veina IT sistema koji se danas koriste u saveznoj vladi su u konstantnom stanju prelaska ili evolucije na novi hardver , softver, ili firmver. Retko se nailazi na uvoenje kompletno novih sistema. Zbog toga C&A proces treba da bude dovoljno fleksibilan i dinamian da se moe odnositi na sve savezne IT sisteme na ma kom stupnju svog ivotnog ciklusa. Na primer, kada se porede stari sistemi (tipino imaju mnogo manje informacija)sa novim sistemima ili sistemima koji se sada razvijaju, moe se uoiti znaajna razlika u tipu i nivou projektne dokumentacije. Ova mala razlika, moe uticati na stepen i strogost anali ze i procene aktivnosti koje se mogu uvoditi za vreme C&A. Prema tome, C&A proce s, pridruene aktivnosti, zadaci i podzadaci, moraju reflektovati ove mogue razlike i biti projektovani tako da koriste ma koje raspoloive informacije koje mogu pom oi ovlaenim slubenicima pri donoenju odluke, na bazi procene rizika, ili pri putanju s istema u rad kao i autorizaciji neprekidnog rada sistema. 1.4 Programi evaluacije komponenti proizvoda IT sistemi se nabavljaju ili razvijaju da bi se zadovoljile odreenje potrebe, a t ipino se koriste komercijalni off-the-shelf (COTS) proizvodi kao to su operativni si stemi, baze podataka, firewalls, mreni ureaji, web browseri, smart kartice, biomet riki ureaji, komponente za aplikacije opte namene kao i hardverske platforme. Bezbe dnost na kontramere implementirane u jedan IT sistem, tipino, koriste funkcije pr oizvoda koji se nalaze u sloju ispod i zavise od korektnog rada i bezbednosnih f unkcija ovih proizvoda. Proizvodi takoe mogu biti predmet bezbednosne evaluacije sami po sebi; ovakve evaluacije mogu podrati C&A proces. Standardi, kao to su Opti kriterijum za evaluaciju bezbednosti informacione tehnologije (ISO/IEC standard 15408) i Bezbednosni zahtevi za kriptografske modele (FIPS 140-2), mogu se korit iti da bi se dobila evaluacija specifinih komponenti proizvoda (validacija) i na taj nain podrao C&A proces. 6 Kompletnu listu validiranih COTS proizvoda obezbedio je NIST na web stranici http://csrc.nist.gov/cryptval i http://niap.nist.gov/cc -scheme. Korienje validiranih procesa moe znaajno smanjiti trokove C&A, uzimajui u obz ir testove i rezultate evaluacije ili dajui informacije o tome kako se bezbedno k onfigurie odreeni proizvod u okviru sistema. Tamo, gde su ukljueni proizvodi kompon ente, ili se razmatra njihovo ukljuivanje u vie IT sistema, takoe se smanjuju trokov i pri evaluaciji bezbednosnih aspekata takvih nezavisnih proizvoda i gradnja sis tema od katalokih proizvoUprkos injenici da se evaluatori mogu osloniti na predhod ne evaluacije invidiualnih komponenti sistema (koje su propisno instalirane i ko nfigurisane), i da dalje se mora uraditi evaluacija integrisanog sistema da bi s e postigla sigurnost da u procesu integracije nisu ostale bezbednosne rupe. 6 10

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema da za koje je izvrena evaluacija. Rezultati jedne ovakve evaluacije treba da budu iskazani na nain koji podrava C&A proces i u gradnju ovih proizvoda u jedan IT si stem bez nepotrebne reevaluacije. Uputstvo za bezbedno konfigurisanje T&O proizv oda moe biti instrument koji e pomoi agencijama da razviju, rade i odravaju vie bezbe dnih sistema. 1.5 Odnos prema drugim NIST publikacijama Specijalna publikacija 800-37 koristi nekoliko NIST publikacija7 koje podravaju C &A proces: Special Publication 800-18, Guide for Developing Security Plans for I nformation Technology Systems, December 1998; Special Publication 800-30, Risk M anagement Guide for Information Technology Systems, January 2002; Special Public ation 800-53, Minimum Security Controls for Federal Information Technology Syste ms, (projected for Spring 2003); and Special Publication 800-53A, Techniques and Procedures for the Verification of Security Controls in Federal Information Tec hnology Systems, (projected for Spring 2003). Druge NIST specijalne publikacije obezbeuju dodatna uputstva u irokom spektru tema koje se odnose na bezbednost uklj uenih u C&A proces: Special Publication 800-12, An Introduction to Computer Secur ity: The NIST Handbook, October 1995. Special Publication 800-14, Generally Acce pted Principles and Practices for Security Information Technology Systems, Septe mber 1996; Special Publication 800-16, IT Security Training Requirements: A Role -and PerformanceBased Model, April 1998; Special Publication 800-26, Self-Assess ment Guide for Information Technology Systems, November 2001; Special Publicatio n 800-27, Engineering Principles for Information Technology Security (A Baseline for Achieving Security), June 2001; Special Publication 800-33, Underlying Tech nical Models for Information Technology Security, December 2001; Special Publica tion 800-34, Contingency Planning Guide for Information Technology Systems, June 2002; and Special Publication 800-47, Security Guide for Interconnecting Inform ation Technology Systems, September 2002. Dokumenta sa uputstvima o bezbednosti koji su nabrojani u ovoj glavi su preporuen i za upotrebu u svim saveznim agencijama. Meutim, neke agencije mogu upotrebiti i druge procedure i/ili formate za pravlljenje plana bezbednosti i voenju aktivnos ti upravljanja rizikom. C&A proces definisan u ovim publikacijama omoguava moguu r azliitost 7 11

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Slika 1.1. ilustruje odnos izmeu NIST specijalnih publikacija 800-37 i drugih spe cijalnih publikacija koje podravaju C&A proces. Ove publikacije se mogu dobiti od NIST Computer Resource Center (http://csrc.nist.gov) Slika 1.1 Specijalne publikacije koje podravaju C&A proces 1.6 Organizacija specijalnih publikacija Ove specijalne publikacije sadre etiri glavne glave i etiri priloga. Glava jedan uv odi osnove C&A, ukljuujui namenu i okvir primenljivosti. Glava dva opisuje osnovne koncepte vezane za C&A program i ukljuuje uloge i odgovornosti glavnih uesnika, t ipove IT sistema koji su predmet akreditacije, akrediticiaone kategorije i tipov e akreditacionih odluka. Glava tri opisuje proces odreivanja odgovarajueg Sertifik ovanog nivoa bezbednosti (SCL) i odnos izmeu sertifikacionih nivoa i odreenih kont rola bezbednosti sistema. Glava etiri daje pregled razliitih faza C&A procesa i uk ljuuje kratak opis 12

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema zadataka u okviru svake faze. Prilozi daju detaljnije informacije vezane za C&A i ukljuuju reference, renik, listu skraenica, i primer akrediciaonih pisama. 13

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Glava 2 OSNOVE C&A PROCESA KLJUNI UESNICI, TIPOVI SISTEMA I AKREDITACIONE KATEGORIJE Programi postojeih agenci ja za bezbednost, razmatraju i tehnike i ne-tehnike mere za izgradnju sigurnijih s istema i na taj nain poveavaju poverenje pojedinih korisnika u bezbednost tih sist ema Ova glava opisuje osnove C&A procesa, ukljuujui ulogu i odgovornost kljunih uesn ika u C&A procesu, tipove IT sistema koji mogu biti sertifikovani i akreditovani , kao i razliite kategorije akreditacije, koje postoje u saveznim agencijama. Ova glava se odnosi i na postavljanje granica akreditacije, primenu C&A procesa na velike i sloene sisteme i tipove akreditacionih odluka koje se mogu pruiti, kao i posledice ovih odluka na bezbednost sistema i agenciju. 2.1 Uloge i odgovornosti Tokom celog ivotnog ciklusa jednog IT sistema uestvuje dosta ljudi sa razliitim ulo gama i odgovornostima, koje se reflektuju na C&A proces,. C&A proces, opisan u s pecijalnoj publikaciji, dozvoljava da agencije prilagode odreene C&A uloge, prema svojoj organizacionoj strukturi, da bi na najbolji nain upravljale rizikom u odn osu na poveren im zadatak. Kao to e biti dalje diskutovano, postoji nekoliko vanih uloga koje su definisane u tipinom C&A programu: (1) ovlaeni slubenik - esto nazivan kao Imenovani autoritet za odobravanje (DAA), (2) slubenik koji potvruje, (3) ruko vodilac programa ili vlasnik sistema i (4) inovnik za bezbednost sistema. Da bi s e poveao integritet i objektivnost pri donoenju akreditacione odluke, mogu se uves ti i dodatne uloge. Stvarne titule mogu biti razliite, ali su odgovornosti iste. Broj uesnika u C&A procesu i njihove uloge e se razlikovati od agencije do agencij e, u zavisnosti od skupa uputstava, ovlaenog slubenika, raspoloivosti resursa, nivoa uloenog napora u sertifikaciju, zahteva u odnosu na bezbednost, osetljivost i kr itinost sistema. Uloge i odgovornosti kljunih uesnika u C&A programu e dalje biti di skutovane. 2.1.1 IMENOVANI AUTORITET ZA ODOBRAVANJE (DAA) DAA je stariji rukovod ei slubenik ili izvrilac sa ovlaenjem da formalno odobri rad jednog IT sistema na pri hvatljivom nivou rizika. Podrazumeva se da DAA u postupku akreditacije ima odgov ornost za rizik rada sistema u odreenom okruenju. Ovi slubenici imaju ovlaenja da nad gledaju i utiu na budet i poslovne operacije sistema, koji su u njihovoj nadlenosti . DAA takoe odobrava dokumenta o zahtevima u odnosu na bezbednost, memorandume sp orazuma (MOA), memorandume sporazumevanja (MOU) i ma kog odstupanja od politike bezbednosti. Dodatno, kao to je ovlaen za odobravanje i 14

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema putanje sistema u rad, DAA ima ovlaenja da ukoliko postoji neprihvatljiv rizik u od nosu na bezbednost sistema, ne odobri rad sistema, tj. da ako je sistem ve u upot rebi, zaustavi rad sistema. Na osnovu informacija koje se nalaze u konanom paketu za sertifikaciju, (npr. plan bezbednosti, razvojni i/ili izvetaji testa bezbedno sti i procene (ST&E), izvetaj o riziku i izjava sertifikatora) DAA moe doneti odlu ku, zasnovanu na proceni rizika: (1) odobrenje akreditacije sistema (2) privreme no odobrenje za korienje sistema ili (3) odbijanje akreditacije sistema, jer su ri zici kojima je sistem izloen neprihvatljivi. Odluka o akreditaciji se dokumentuje u konanom akreditacionom paketu, koji sadri akreditaciono pismo, prateu dokumentac iju i obrazloenje akreditacione odluke. U nekim situacijama, moe se ukljuiti vie DAA za akreditaciju jednog sistema. Ukoliko je to sluaj, mora se postii saglasnost sv ih DAA, s tim da se ona dokumentuje u akreditacionom paketu. U veini sluajeva pred nost je imati saglasnost sa vodeim DAA, koji u celom C&A procesu reprezentuje sve DAA. 2.1.2 SERTIFIKATOR I SERTIFIKACIONI TIM Sertifikacioni agent, ili sertifik ator, je osoba odgovorna za tehniku procenu usaglaenosti IT sistema sa postavljeni m zahtevima u odnosu na bezbednost, za identifikaciju, procene i dokumentovanje rizika rada sistema, koordinaciju sertifikacionih aktivnosti i konsolidaciju kon anog C&A paketa. Sertifikator i sertifikacioni tim obezbeuju ekspertizu za voenje n ezavisne tehnike i ne-tehnike evaluacije sistema, na osnovu zahteva u odnosu na be zbednost sistema i kontrolu bezbednosti, dokumentovanih u planu bezbednosti. Ser tifikator procenjuje mogue pretnje sistemu, odreuje da li su kontrole korektno imp lementirane i odreuje nivo zaostalog rizika. Da bi se sauvala nepristrasnost i nez avisnost postupka sertifikicinog procesa, sertifikator treba da bude u poziciji da je nezavisan od lica koja su direktno odgovorna za razvoj sistema i njegov sv akodnevni rad. Sertifikator treba takoe da bude nezavisan i od onih lica koji su odgovorna za korigovanje odstupanja zahteva u odnosu na bezbednost, uoenih za vre me sertifikacionog procesa. Organizaciona nezavisnost sertifikatora obezbeuje da DAA dobija najobjektivnije informacije, koje je mogue dobiti, i na osnovu njih do nese akrediticionu odluku, zasnovanu na informacijama i proceni rizika. 2.1.3 RU KOVODILAC PROGRAMA I VLASNIK SISTEMA Rukovodilac programa i vlasnik sistema pred stavljaju interese korisnika IT sistema tokom celog ivotnog ciklusa sistema. Ruko vodilac programa je odgovoran za sistem za vreme poetnog razvoja i akvizicije, a brine se o trokovima, planu, i izvravanju plana. Podrazumeva se da vlasnik sistema , ima odgovornost za sistem, poto je sistem isporuen i instaliran, to jest za vrem e rada, odravanja i prestanka rada sistema. Rukovodilac programa i vlasnik sistem a e obezbediti da se sistem razvije i radi prema zahtevima u odnosu na bezbednost , koji su dokumentovani u planu bezbednosti, a takoe i da korisnici sistema i per sonal, koji radi na bezbednosnoj zatiti, dobiju adekvatnu obuku o bezbednosti sis tema (na primer instrukcije i pravila o ponaanju). Rukovodilac programa i vlasnik sistema 15

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema

koordiniraju C&A napore i obezbeuju, kada je to neophodno, potrebno osoblje i inf ormacije sertifikatoru i sertifikacionom temu. Rukovodilac programa i vlasnik si stema verovatno snose trokove sertifikacionog rada, i mogu pregledati sertifikaci oni izvetaj, pre nego to se on dostavi DAA na dalje razmatranje. 2.1.4 INOVNIK ZA B EZBEDNOST SISTEMA Za sisteme koji su u upotrebi, inovnik za bezbednost sistema je odgovoran za svakodnevnu bezbednost odreenih komponenti IT sistema, ukljuujui i fi ziku sigurnost, linu sigurnost, rukovanje u incidentnim situacijama, svest o bezbe dnosti, obuku i obrazovanje. Taj inovnik za bezbednost sistema pomae u razvoju pol itike bezbednosti sistema, i obezbeuje saglasnost sa konstantnom politikom. inovni k za sigurnost sistema, identifikuje i sisteme za koje jo nije doneta odluka ili sisteme kojima je promenjeno okruenje koje e zahtevati resertifikaciju ili re-akre ditaciju sistema. Za sisteme koji su u razvoju, inovnik bezbednosti sistema preds tavlja tehnikog savetnika, rukovodioca programa za sva pitanja vezana za bezbedno st. 2.1.5 DRUGE ULOGE I NJIHOVO DODELJIVANJE U PROCESU C&A Postoje i druge osobe u agenciji kao to je predstavnik korisnika, rukovodilac programa bezbednosti, ru kovodilac operacija i rukovodilac instalacija koji su vezani za C&A proces. Pred stavnik korisnika predstavlja operativni interes drutva korisnika i slui kao veza prema tom drutvu u toku celog ivotnog ciklusa sistema. On pomae u C&A procesu, ukol iko je potrebno, a uestvuje i u nadgledanju ispenjenosti zahteva bezbednosti post avljenih u planu bezbednosti. Rukovodilac programa bezbednosti je odgovoran za p rimenu standardnog C&A procesa u celoj agenciji, obezbeuje interna uputstva i pol itiku za C&A proces ili ukoliko to odgovara, pregleda sertifikacione pakete pre nego to ih pregleda DAA. Rukovodilac operacija nagleda da se u operacije vezane z a bezbednost i administraciju IT sistema ukljui izvravanje backup-a, dranje kurseva , odravanje kriptografskih kljueva, briga za administraciju korisnika i privilegij a pristupa, i auriranje softvera za bezbednost. Rukovodilac kapaciteta nadgleda p romene i dodatke koji omoguavaju lake odravanje IT sistema, a da se ne ugrozi bezbe dnost postojeih sistema. Neke C&A uloge mogu biti delegirane, kao diskreciono pra vo starijih slubenika agencije. Slubenici agencije mogu odrediti lica sa odgovaraj uom kvalifikacijom, ukljuujui izvoae radova, da izvre aktivnosti pridruene odreenoj C ulozi. U tom sluaju su odreena lica u mogunosti da rade sa ovlaenjem agencije, u gran icama definisanim za navedene aktivnosti. Pri tom zvaninici agencije zadravaju kra jnju odgovornost i za rezultate i akcije koje su izvrila ova delegirana lica. Ulo gu i odgovornost za potpis DAA ne treba delegirati izvoaima radova. DAA uloga je n erazdvojna od ovlaenja vlade SAD, koja treba da se dodeli samo personalu vlade.8 S lika 2.1 ilustruje uloge i odgovornosti kljunih uesnika u C&A procesu. Agencije treba da potrae savet od Kancelarije generalnog saveta, pre nego to ukljue mogunost izuzea iz ove prakse i delegiraju ovlaenja za autorizaciju ne-vladinom per sonalu. 8 16

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Slika 2.1 Kljuni uesnici C&A procesa 2.2 IT sistemi Uopte govorei, IT sistemi koji se nalaze pod kontrolom saveznih agencija, spadaju u jednu od dve kategorije: glavne aplikacije ili opti sistemi za podrku. Po OMB ci rkularnom pismu A-130, zahteva se da svi sistemi (i glavne aplikacije i opta podrk a) budu odobreni za upotrebu. C&A proces se moe primeniti na oba tipa, kao to e dal je biti objanjeno. 2.2 1 GLAVNE APLIKACIJE Sve savezne aplikacije imaju vrednost i zahtevaju neki nivo sigurnosti. Neke aplikacije, zbog naina obrade, uvanja ili p renosa informacija ili zbog kritinosti aplikacije za glavni zadatak agencije, zah tevaju specijalni tretman od strane rukovodstva. Ove aplikacije se nazivaju glav ne aplikacije. Glavne aplikacije su sistemi koji izvravaju jasno definisane funkc ije za koje postoje spremne identifikovane potrebe vezane za bezbednost (npr. Si stem za elektronski prenos fondova ili globalni komandni i upravljaki sistem). Gl avna aplikacija moe ukljuivati mnogo individualnih programa, hardvera, softvera i telekomunikacionih komponenti. Ove komponente mogu biti jednostavne aplikacije i li kombinacija 17

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema hardvera/softvera koje su usmerene na podrku specifinim funkcijama vezanim za izvra vanje glavnog zadatka. Glavna aplikacija se moe sastojati i od nekoliko posebnih aplikacija, ukoliko se sve one odnose na jednu funkciju glavnog zadatka (npr. Ob raun plata ili kadrovska evidencija). 2.2 2 SISTEMI ZA OPTU PODRKU Sistemi za optu podrku predstavljaju kolekciju meusobno povezanih informatikih resur sa ili raunarskih okruenja, koji rade pod istom kontrolom i dele srodnu funkcional nost. Sistemi za optu podrku obino ukljuuju hardver, softver, informacije, podatke, aplikacije, komunikacije, opremu i ljude, i obezbeuju podrku za razliite korisnike i/ili uobiajne aplikacije. Sistem za optu podrku, na primer, moe da bude lokalna mrea (LAN) ukljuujui inteligentne terminale, koja podrava rad regionalnih odeljenja, mr ena kima (na primer, mrea u celoj agenciji), komunikaciona mrea, odeljenje za obradu podataka koji ukljuuju njihove operacione sisteme i opremu, taktika radio-mrea, od eljenje za office automatizaciju i servis elektronske pote, ili organizacija serv isa za obradu podataka koje deli vie organa. Takoe, sistem za optu podrku moe sadrati jednu ili vie glavnih aplikacija. Od agencije se oekuje da obui rukovodstvo za proc enu aplikacija, koje se smatraju glavnim, i da osiguraju da zahtevi bezbednosti nebitnih aplikacija budu razmatrane u okviru bezbednosti aplikacija sistema opte podrke. 2.2 3 BAZA IT MEUPOVEZIVANJA I IZMETENI IT PROCESI Pri identifikaciji siste ma za C&A, treba razmotriti i dva specijalna sluaja glavnih aplikacija ili aplika cija sistema opte podrke: 1) osnovu IT meupovezivanja, 2) izmetanje IT procesa. Osno va IT meupovezivanja se odnosi na mreni pristup raunarskim resursima, i hardverski i softverski, koji su fiziki deo, posveeni ili osnovni u realnom vremenu za izvrava nje misije sistema specijalne namene kao to je sistem naoruanja, simulatori za veba nje, dijagnostiki testovi i oprema za odravanje, oprema za kalibraciju i oprema ko ja se koristi pri elektronskim istraivanjima i razvoju sistema naoruanja, medicins kim tehnologijama, transportu vozila, sistemu nabavke (na primer, vode i distrib ucije elektrine energije). Izmeteni IT proces je opti termin, koji se koristi da uk ae na izmetene poslovne procese koje podrava privatni sektor IT sistema, izmetene in formacione tehnologije ili izmetene informacione servise. I baza IT meupovezivanja i izmeteni IT-bazirani procesi, imaju pravila bezbednosti i potrebe koje se lako mogu identifikovati, a koje treba razmotriti u C&A procesu. Uobiajno, C&A proces definisan u ovim specijalnim publikacijama moe biti lako usvojen za ovako specij alne sluajeve. 2.3 Katagorije akreditacije Postoje tri tipa akreditacije koji se mogu dobiti od federalne agencije: 1) sist em akreditacije, 2) tip akreditacije i 3) mesto akreditacije. Kategorija akredit acije je vaan koncept koji ima glavnu ulogu u narednim zadacima i podzadacima pre duzetim tokom C&A procesa. Akreditaciona kategorija opisuje kako bi IT sistem tr ebalo posmatrati u toku C&A procesa 18

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema to znai, kao jednu od vrsta glavnih aplikacija ili opti sistem podrke, vie kao generik u aplikaciju ili sistem koji bi bio ponovljen na vie lokacija, ili kao grupu apli kacija i/ili sistema uobiajenom nadlenom telo za akreditaciju, samo-odravajuim lokac ijama, ili odgovarajuim geografskim oblastima. Svaka akreditciona kategorija upuuj e razliite akreditcione potrebe i sertifikate koji se odnose na sertifikacione pr ocese koji se odnose na njih. Autorizovani predstavnici treba da izaberu tip akr editacija koje najvie odgovaraju potrebama agencija. Akrediticione kategorije su detaljno objanjene u daljem tekstu. 2.3 1 SISTEMI AKREDITACIJA Sistem akreditacij e je najei oblik akreditacije, koji autorizuje rad glavne aplikacija ili sistema opt e podrke na odreenoj lokaciji sa specificiranim ogranienjima u odnosu na okruenje si stema. Sistem akreditacije za veinu glavnih aplikacija ili sistema opte podrke je g arantovan, ukoliko informacioni resursi zahtevaju specijalne mere bezbednosti zb og rizika i vee osetljivosti na gubitak, nepravilnu upotrebu ili neautorizovan pr istup/ modifikaciju informacija ili ukljuenje informacionih resursa. Sertifikacio ni proces e proceniti sve bitne stavke kontrole bezbednosti (upravljanje, rukovoen je, i tehniku kontrolu) za glavne aplikacije ili sistem opte podrke i kao rezultat e biti akreditacija autorizovane operacije na dogovorenom nivou preostalog rizika . Slika 2.2 ilustruje koncept sistema akreditacije. Slika 2.2 Sistem akreditacije 2.3 2 TIP AKREDITACIJE U nekim situacijama je glav na aplikacija ili sistem opte podrke predvien za instalaciju na vie lokacija. Aplika cija ili sistem obino sadri uobiajeni skup hardvera, softvera i firmvera. S obzirom da je teko akreditovati uobiajenu aplikaciju ili sistem na svim moguim lokacijama, DAA moe izdati tip akreditacije za tipina radna okruenja. Tip 19

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Slika 2.3 Tip akreditacije akreditacija su forma meu akreditacija koje se koriste da sertifikuju i akredituju vei broj pojavljivanja glavne aplikacije ili sistema opte podrke, za rad na odobrenim lokacijama istog tipa raunarskog okruenja. DAA mor a dati izjavu o preostalom riziku, kao i jasnu definiciju radnog okruenje za glav ne aplikacije ili sistem opte podrke. Takoe, DAA mora da identifikuje specifino korien je aplikacija ili sistema opte podrke, kao i ogranienja rada i procedura pod kojim aplikacija ili sistem moe da radi. Tip akreditacija predstavlja jedan efikasan nai n za akreditaciju glavnih aplikacija i sistema opte podrke, koji ispunjava bezbedn osne zahteve i koristi odabrane sigurnosne kontrole za svaku aplikaciju ili sist em koji se instalira na vie lokacija. Tip akreditacija ima namenu da znaajno smanj i vreme trajanje procene, jer je lokalnoj organizaciji dostavljena poetna dokumen tacija sistema potrebna za akreditaciju, ukljuujui i posebne procedure bezbednosti rada. Da bi se podrao tip akreditacija glavnih aplikacija i sistema opte podrke, u sluaju da test lokacije nisu dostupne, osnovni bezbednosni testovi i procena (ko ji se nazivaju i Sigurnosni test i procena (ST&E)), treba da se urade u centraln om prostoru za testiranje i integraciju ili u jednom od predvienih radnih lokacij a. Bezbednosno testiranje softvera i hardvera zajednikih sistemskih komponenti se ne preporuuju na vie lokacija. Na kraju razvojnog sigurnosnog testa i procene (ST &E), plan sistema bezbednosti, izvetaj o razvojnom ST&E i izvetaj poetna procena ri zika se prilau zavrnom razvojnom sertifikacionom paketu i prosleuje, zajedno izjavo m o sertifikaciji nadlenom DAA.9 Akrediticioni paket, koji sadri plan bezbednosti i dokumentaciju koja obrazlae akreditacionu odluku se alje zajedno sa softverom i hardverom na sve lokacije gde treba instalirati glavnu aplikaciju ili sistem opte podrke. Dalje, na tim lokacijama ne treba ponavljati osnovne stavke testa sigurn osti i U toku razvoja i akvizicije novog sistema, autorizovani predstavnici podeavaju ti p akrediticaonih odluka to je ponekad naziva razvojni DAA. Razvojni DAA identifik uje i prihvata rizik u projektovanju novog sistema i odgovoran je za razumevanje tipinog radnog okruenja u kome e sistem biti primenjen, a zahtevi sigurnosti siste ma ispunjeni. Tip akreditacije i odgovarajuu dokumentaciju e koristiti radni DAA, koji zatim preuzima sistem na terenu i inicira lokalnu akreditaciju, prihvatajui odgovornost za sistem konfiguracije, radno okruenje i radni rizik. 9 20

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema procene koje su uradjene u postupku tip akreditacije. Meutim, sistem instalacije i konfiguracija sigurnosti treba da bude testirana za vreme svakoj radnoj lokaci ji u okviru radnog (lokalnog) testa sigurnosti i procene. Tip akreditacije ukljuu je odgovornost lokalnih zaposlenih za nadgledanje slaganja radnog okruenja sa pre dvienim okruenjem i odobrenoj konfiguraciji, koja je opisana u dokumentaciji o akr editaciji. Slika 2.3 ilustruje koncept tipa akreditacije. 2.3 3 LOKALNA AKREDITA CIJA Ukoliko postoji vie agencija, koje se nalaze na istoj lokaciji u okviru jedn e geografske oblasti, a rade pod kontrolom zajednikog vieg izvrioca, suoene sa istim opsanostima po sistem, dele zajedniku strategiju i imaju uporedive slabosti, tad a DAA moe izdati lokalnu akreditaciju, koja je primenjiva na sve glavne aplikacij e i/ili sisteme opte podrke na toj lokaciji.. Lokalna akreditacija je usmerena na dobijanje akreditacije jednog kapaciteta i grupe aplikacija i tamo postojeih sist ema. Slika 2.4 ilustruje koncept lokalne akreditacije. Slika 2.4 Lokalne akreditacije 2.4 Sertifikaciona i akrediticiona dokumentacija Ne treba zaboraviti, da je cilj C&A procesa da obezbedi potrebne informacije, na osnovu kojih bi DAA doneo obrazloenu odluku, zasnovanu na proceni rizika, u vezi sa radom jednog IT sistema u zadatom okruenju. Kao takav, svaki zadatak i podzad atak u C&A procesu, je paljivo promiljen, da podri aktivnosti testova sigurnosti i procene neophodnih za odreivanje saglasnosti sa zahtevima sigurnosti sistema sa j edne strane i primeni propisanih kontrola, koje su navedene u planu bezbednosti, a zatim korektno i efikasno primenjene. Paket sertifkacije je konani skup dokume nata, koje je pripremio sertifikator i sertifikacioni tim za DAA. Sertifikacioni paket obino sadri: 1) plan bezbednosti (pregledan i dopunjen prema potrebama), 2) razvojni i/ili radni izvetaji testova sigurnosti i procene, 3) 21

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema zavrni izvetaj o proceni rizika i 4) izjava sertifikatora. Svaki od dokumenata je ukratko opisan u daljem tekstu. 2.4 1 PLAN SISTEMA BEZBEDNOSTI Plan sistema bezb ednosti ima centralnu ulogu u oblasti upravljanja rizikom i C&A procesima kao i u dokumentovanju bezbednosne pozicije jednog IT sistema agencije. Namena plana b ezbednosti je da obezbedi pregled zahteva bezbednosti jednog IT sistema i da opie postojae ili planirane mere kontrole bezbednosti (rukovodne, radne, tehnike) za i spunjenje ovih zahteva. Plan bezbednosti daje potpun opis sistema i usmerava odg ovornosti i oekivano ponaanje lica koji pristupaju sistemu. Agencije koje imaju na pravljen kompletan plan bezbednosti pre poetka C&A procesa, mogu efikasno da kori ste informacije koje su sadrane u planovima u cilju podrke poetnim pre-sertifikacio nim aktivnostima. Agencije koje nisu kompletirale svoj plan bezbednosti, mogu iz vesti potrebne informacije za planove povezivanjem osnovnih pre-sertifikacionih aktivnosti, koje su odreene C&A procesima. Treba zapaziti da je plan bezbednosti i v dokument, koji se dopunjava tokom celog ivotnog ciklusa sistema, kako nove info rmacije postaju dostupne. Ukoliko je plan bezbednosti napravljen pre nego to je s istem proao procenu rizika, naknadno ga treba dopuniti rezultatima procene rizika . Minimalno, Plan bezbednosti treba da sadri informacije navedene u specijalnoj p ublikaciji Nacionalnog Instituta za standarde bezbednosti, 800-18, Vodi razvoja p lana bezbednosti IT sistema, Decembar 1998. U skladu sa direktivama agencije DAA ima diskreciono pravo da ukljui dodatne informacije. 2.4 2 IZVETAJI TESTA BEZBEDN OSTI I PROCENE ST&E aktivnosti su osnovna komponenta C&A procesa. Namena ST&E je odreivanje uskl aenosti IT sistema sa zahtevima bezbednosti dokumentovanim u planu bezbednosti, k ao i verifikacija da su identifikovane kontrole bezbednosti u planu korektno i e fikasno primenjene. Postoji dva posebna tipa ST&E koji se mogu primeniti tokom C &A procesa: 1) razvojni ST&E, 2) radni ST&E. Razvojni ST&E se primenjuje za nove sisteme (ili sisteme koji su u procesu znaajne modifikacije) u fazi razvoja i ak vizicije ivotnog ciklusa sistema. Radni ST&E se primenjuje za nove ili unapreene s isteme (po isporuci i zavretku instalacije sistema) u fazi implementacije sistema ili na postojeim sistemima u fazi rad / odravanje. Razvojni izvetaji ST&E tipino sa dre rezultate testova i procene vezane za hardver, softver i firmver sistema (ukl juujui analize arhikteture sistema i funkcijalno testiranje) da bi se izvrila verif ikacija korektne implementacije tehnikih mera sigurnosti, kao i njena efikasnost pri ispunjavanju standarda bezbednosti zahtevanih za taj sistem. Razvojni ST&E s e mnogo vie oslanja na detaljnu dokumentaciju projektovanja sistema, koja je obino raspoloiva samo za nove sisteme. 10 Radni ST&E izvetaji bezbednosti, tipino sadre r ezultate testiranja i procene koje su raene na lokalnom IT sistemu, da bi se veri fikovalo da je tehnika, rukovodea i radna kontrola bezbednosti korektno implementi rana i da je efikasna u ispunjenju zahteva bezbednosti sistema. Radni ST&E moe da ukljui i funkcionalno testiranje, testiranje prolaznosti kao i analize osetljivo sti. Za nove sisteme (ili 10 Razvojni ST&E izvetaji se prave za sisteme koji su tip akreditovani, kao meukorak pre finalne akreditacijie na radnoj lokaciji. 22

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema sisteme koji su u procesu znaajne modifikacije) u postupku C&A koristie se i razvo jni i radni ST&E izvetaj. Za postojae sisteme (ili sisteme sa malim modifikacijama ) u postupku C&A e se koristiti samo jedan radni ST&E izvetaj. 2.4 3 IZVETAJ PROCEN E RIZIKA Procena rizika odreuje stepen rizikakoji se pridruuje privatnosti, integr itetu i raspoloivosti IT sistema i informacija koje ovaj sistem obrauje, uva i pren osi. Izvetaji procene rizika dokumentuju rezultate aktivnosti procene rizika uklj uujui opasnosti i osetljivost sistema, predloge za procenu efikasnosti kontrola be zbednosti, za i protiv argumrnti pridrueni predloenim kontrolama (na primer, utica j na izvravanje i cenu) i preostali rizik udruen sa skupom skupom predloenih kontro la. Za svaki preostali rizik, izvetaj precizira obrazloenje za prihvatanje ili odb ijanje rizika, kao i mogue budue kontrole sigurnosti za smanjenje rizika. Sertifik ator procenjuje zavrni izvetaj procene rizika, paljivo odreujui irinu i pouzdanost ono g to je pronaeno. Izvetaj sertifikatora za DAA zasnovan je na informacijama koje se nalaze u izvetaju procene rizika i drugim dodatnim dokumentima. DAA koristi izvet aje procene rizika zajedno sa ostalim dokumentima donetim u sertifikacionom pake tu, da bi doneo zavrnu akreditacionu odluku. Izvetaj procene rizika,kao minimum, t reba da sadri informacije odreene u specijalnoj publikaciji 800-30 Nacionalnog Ins titutu za standarde bezbednosti, Vodi upravljanja rizikom za IT sisteme, oktobar 2001. Plan bezbednosti sistema treba da bude modifikovan tako da ukljui pronalaene i planirane aktivnosti koje proizilaze iz procene rizika. U skladu sa direktiva ma agencije DAA ima diskreciono pravo da ukljui dodatne informacije. 2.4 4 IZVETAJ SERTIFIKATORA Izvetaj sertifikatora daje pregled statusa bezbednosti sistema i d ovodi u vezu sve potrebne informacije za DAA, kako doneo odluku zasnovanu na inf ormacijama i proceni rizika. Izvetaj dokumentuje da se kontrole bezbednosti korek tno implementirane i da su efikasne u primeni. Izvetaj takoe dokumentuje i kontrol e bezbednosti koje nisu primenjene i predlae korektivne postupke. 2.5 Akreditacija velikih i kompleksnih sistema Postavljanje odgovarajue i akreditcionih odredbi za C&A proces najee je bio jedan od najizazovnih problema za agenciju. Odpredbe koje su previe skupe predstavljaju C &A proces skuenim i daleko tee podri za veinu agencija. Odredbe koje su i suvie ogran iene poveavaju broj C&A procesa koji treba da budu zavreni i takoe podiu ukupne trokov e agencije. U dodatku dilema akreditcionih odredbi, irenje obstanka velikih i kom pleksnih sistema (glavnih aplikacija i obteg sistema podrke) i je takoe ojaanje sert ifikacionog aspekta C&A procesa. Aplikacija odabrane kontrole bezbednosti (uprav ni, radni, i tehniki) kroz velike i kompleksne sisteme mogao biti nerentabilan i tehniki onemoguen. Prema 23

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema tome, svaki pokuaj da se sertifikuje takav sistem na jednom sertifikacionom nivou ,11 (pirmenjujui isti nivo jaine koji se odnosi na testiranje, procenu i analizu s istema,) da bi se odredila relacija sa zahtevemi bezbednosti sistema, i ukoliko je kontrola sistema korektno primenjena i efikasna takoe moe biti nerealna. Da bi se reio ovaj problem, DAAs treba da se razmotri nain IT sistema, koji odgovara C&A i mogunosti podele sistema na delove lake za upravljanje. Podela velikih i komple ksnih sistema na komponente nivoa sistema, ili subsisteme, korisnike, aplikacije , sertifikacionih procesa na ekonominiji nain i pomae konceptu rizika upravljanja i ulazi u detalje. Strategija detaljisanja podrazumeva da IT sistem moe biti oznaen kao iroko primenjeno povezivanje, krajni skup informacija za mogunost upravljanja kao pojedinano preduzee. Tako, oba i glavne aplikacije i opti sistem podrke, DAA moe da definie skup komponenti podsistema u planu bezbednosti. Svaka komponenta pod sistema je potpuno odreena u planu kao i odgovarajui skup zahteva bezbednosti i ko ntrola bezbednosti odreene za zadate komponente. Na poetku procesa sertifikacije, svaka komponenta pod sistema moe biti sertifikovana na razliitim nivoima sertifika cije u zavisnosti od nivoa sigurnosti12 izraene koju zahteva agencija u odnosu na privatnost, integraciju, i korienje komponenti u samom sistemu. Kritine izuzetno v ane komponente podsistema identifikovane poveanim nivoom sigurnosti privatnosti, i ntegracije ili korienja zahtevaju i primaju mnogo jae, intenzivnije analize tokom s ertifikacionog procesa, od manje vanih, niskog nivoa komponenti podsistema. Final ni sistem akreditacije moe da sadri jednu ili vie komponenti podsistema sertifikova nih za odgovarajui nivo baziranih na dokumentovanom nivou sigurnosti i kontrole b ezbednosti. Sertifikacioni paket je modifikovan tako da ukljuuje raznovrsne izveta je ST&E (jedna za svaku komponentu podsistema) zajedno sa finalnim izvetajem proc ene rizika koji se odnosi opti rizik sistema kao celine. Opti rizik za IT sistem m oe biti vei od ukupnih rizika za komponente individualnog pod sistema. Da bi se il ustrovao jednostavan primer ralanjivanja sistema, sistem opte podrke sadri nadzor koj i posmatra tok informacija izmeu dve lokalne mree, gde sadrane informacije u jednoj od mrea razliitog nivoa osetljivosti od drugih mrea. U ovom sluaju sistem moe biti p odeljen na tri komponente podsistema: 1) lokalna mrea alpha, 2) lokalna mrea bravo , i 3) nadzor koji odvaja dve lokalne mree. Komponente nadzornog sistema treba da budu visoko odgovorne da bi ispunile svoj predvieni bezbednosni zadatak, (jedino u sluaju dozvole za prolazak odreenih informacija izmeu odgovornih lokalnih mrea). Zahtevi bezbednosti i udruenih kontrola bezbednosti koje su aktivne u ovim specif inim komponentama pod sistema mogu biti prilino rairene ukoliko postoji oigledan vis oki nivo sigurnosti u smislu privatnosti informacija u sistemu. Nadzorne kompone nte pod sistema bile Nivoi sertifikacije su opisani detaljnije u podglavlju 3 ove specijalne publikac ije, (primena istog nivoa zahteva sa odreenim testiranjem, procenu, i analizom si stema), zatim za odreivanje odgovarajue veze sa zahtevima sistema bezbednosti i uk oliko je kontrola bezbednosti korektno primenjena i efikasna, takoe moe da bude ne realna) 12 Tokom pre sertifikacione C&A procesa agencije odreuju stepen sigurnost i odreen u planu sigurnosti za privatnost, integraciju i korienje njihovih IT siste ma i procesovanju informacija, uvanje i prenoenje ovim sistemima. Nivo sigurnosti povratno utie na izbor odgovarajue kontrole za sistem i jedinstvene zahteve nivoa sertifikacije. Ove komponente su opisane u podglavlju 3 ove specijalne publikaci je. 11 24

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema bi sertifikovane na viem nivou od dve komponente podsistema lokalnih mrea. Jaina se rtifikacionog procesa na viem sertifikacionom nivou odnosi se na potrebe vee sigur nosti nadzornih verzija ostalih komponenti u sistemu. Dodatno testiranje procena i analiza zahtevane su za svaki naredni nivo sertifikacije. Izolovanim visoko v rednih komponenti podsistema u sistemu i primena odgovarajueg nivoa sertifikacije na ove komponente je ekonomian metod akreditacije IT sistema. ema 2.5 ilustruje k oncept komponenti podsistema i udrue akreditacije za velike i komplikovane sistem e agencije. Slika 2.5 Primer dekomponovanja sistema 2.6 Akreditacione odluke i preostali rizik Nakon kopletiranja sertifikacionog sistema, DAA je predstavljen kljunim informaci jama koje se sadrene u sertifikacionom paketu, (finalni plan sistema bezbednosti, izvetajima ST&E, finalnim izvetajem procene rizika i izvetajem sertifikatora) Sert ifikacioni proces determinie i dokumentovan kada je kontrola bezbednosti pravilno primenjena i kada se efektivno primenjuje u zadovoljavajuim IT sistemima zahteva bezbednosti. Bilo koje preostale osetljivosti u IT sistemu posle primene ovih p ostavljene kontrole bezbednost, predstavlja bazu preostalog rizika za sistem. To je ono to ove dokumentovane informacije koje DAA smatra preostalim rizikom za si stem i odluuje dali da autorizuje procesovanje postavljajui u red i prihvatajui pre ostali rizik. U datoj situaciji DAA e izabrati jednu od sledeih akreditacionih var ijanti kada odreuje finalnu akrediticionu odluku: 1) potpunu akreditaciju, 2) del imina akreditacija, 3) ne privaena akreditacija. 25

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 2.6.1 POTPUNA AKREDITACIJA U sluaju potpune akreditacije zahtevi sistema bezbedno sti su zadovoljavajui i kontrola sigurnosti je korektno potvrena i efektivno radi. Sistem je potvren za rad u predvienom okruenju kao to je naznaeno u planu bezbednost i i nekoliko, ukoliko ih ima, restrikcija primenjenih u procesovanju. DAA izdaje odgovarajui akrediticiano pismo zajedno sa zajedno sa dodatnom dokumentacijom ko ja potvruje akreditacionu odluku. Ova informacija je deo finalnog akreditacionog paketa. Sistem akreditacionih odluka koju daje DAA su opisane zavrnom akreditacio nom paketu. Akreditacioni paket obino sadri sledee: 1) akreditaciono pismo, 2) plan bezbednosti, 3) izvetaj koji dokumentuje osnovu za akreditacionu odluku. U veini sluajeva izvetaj DAA mogu biti izvedene iz informacija dobijenih iz sertifikaciono g paketa. Odreene informacije iz plana bezbednosti, izvetaji ST&E, izvetaja procene rizika mogu, u nadlenosti DAA mogu biti spreene publikovanje u finalnom akreditac ionom paketu u smislu njegove osetljive prirode. 2.6.2 DELIMINA AKREDITACIJA Za d eliminu akreditaciju, sistem trenutno ne odreuje zahteve bezbednosti kao to je dato u planu bezbednosti i svim neophodnim kontrolama bezbednosti koje nisu primenje ne i ne rade efikasno. Sta vie, aktivnosti su kritiki postavljene te sistem postaj e aktivan i ne postoje druge mogunosti da adekvatno predstave aktivnosti13 Delimin a akreditacija ili osnovna potvrda za primenu je privremena potvrda koja moe biti izdata za odreeni period vremena kao to je specificirano u DAA. U koliko DAA name rava da potvrdi tu deliminu akreditaciju radne zabrane postavljaju se da bi se sm anjio poveani rizik i treba da budu paljivo proverene a delimini akreditacioni akci oni plan treba da bude razvijen tako da predstavlja sledee: da aktivira Vitalne p otrebe za brzu uspostavljanje sistema Delimina akreditacija je od najveeg interesa za organizaciju Resursi su dostupni da bi se kompletirao akcioni plan i potrebn i sertifikacioni zadaci Akcioni plan moe biti zavren u okviru dozvoljenog vremena koje speficira DAA i Operacione restrikcije smanjuju rizik do najnieg mogueg nivoa (u tom trenutku) i preostali rizik je prihvatljiv DAA izdaje odgovarajue akredet iciono pismo prema gornjim uslovima i restrikcijama i donosi dodatnu dokumentaci ju, ako je neophodno. Tipovi akreditacija smatraju se kao delimina akreditacija s ve dok se operativni ST&E ne budu sproveden da bi lokalno odgovarajui zahtevi bez bednosti ne budu zadovoljeni i dok lokalno odgovarajua kontrola bezbednosti ne bu de pravilno primenjena i efikasna. Kada je jednom uspostavljena akreditacija, DA A na operativnoj i radnoj lokaciji prihvata odgovornosti za bezbednost sistema i za informacije u procesiranju, uvanju i prenoenju. Ovaj tip nepodpune akreditacije moe biti neophodan za mnoge postojae sisteme koji ne odgovaraju zahtevima bezbednosti, ali moraju da funkcioniu dok sistem zamene ( ili glavni sistem bude dopunjen) bude prihvaen. 13 26

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 2.6.3 NEPRIHVAENA AKREDITACIJA U sluaju neprihvaene akreditacije sistem ne odgovara zahtevima bezbednosti i kontrole bezbednosti kao to je zahtevano u planu bezbedn osti; preostali risk je takoe ogroman i aktivnosti kritiki ne odgovaraju trenutnim radnim potrebama. Dakle, Razvojni sistem nije potvren za rad ili ukoliko sistem ve radi, operacioni sistem se zaustavlja. DAA izdaje odgovarajue akreditaciono pis mo o neprihvatanju ukljuujui dodatnu dokumentaciju koja potvruje odluku o neprihvat anju akreditacije. 27

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Glava 3 KONTROLA BEZBEDNOSTI I NIVOI SERTIFIKACIJE PRILAGOAVANJE PROCESA POTREBAMA AGENCIJE Prema vrednosti sastava vaih informacija i zakonitosti, realne opasnosti ovakvog sastava informacija su kritine za odreivan je agencijskog nivoa potreba bezbednosti, tako da je skup resursa koji se racija lno primenjuje da bi se postigla primena bezbednosti... Ovo podglavlje opisuje p roces odabira kontrola bezbednosti potrebnih da na odgovarajui nain zatite IT siste m i odredi odgovarajui sertifikacioni nivo za sistem. Da bi se ovaj proces podrao, vano je razumeti osnovne karakteristike IT sistema u odnosu na bezbednost. Ove k arakteristike, izraene u konceptu sistema kritinost/osetljivost i izloenost sistema unutranjim i spoljanim opasnostima, utiu na jedinstven izbor kontrola bezbednosti i nivo sertifikacije. Uvodni deo ovog poglavlja opisuje, kako treba okarakterisa ti jedan IT sistem, a naredna poglavlja opisuju kako karakterizacija sistema utie na izbor kontrole bezbednosti i nivo sertifikacije. Selekcija kontrole bezbedno sti i nivoa sertifikacije za IT sistem, moe biti upotpunjena nezavisno jedna od d ruge, vezano za nivo brige agencije u odnosu na privatnost, jedinstvenost, upotr ebljivost i izloenost sistema. Odreene kontrole bezbednosti IT sistema mogu se dob iti korienjem NIST Specijalne publikacije 800-53, Minimalne kontrole bezbednosti z a federalni sistem informacione tehnologije (pripremljen za prolee 2003). 3.1 Karakterizacija sistema informacione tehnologije Vano je paljivo okarakterisati IT sistem u cilju upostavljanja odgovarajuceg okruen ja za selekciju odroenih kontrola bezbednosti kontrola koje su u krajnjem odgovor ne za bezbednost sistema, a koje zadovoljavaju agencijske zahteve bezbednosti. K arakterizacija jednog IT sistema se moe ostvariti na sledei nain: 1) ispitivanjem k ritinosti / osetljivosti sistema i informacija koje sistem obrauje, uva i prenosi 2 ) ocenjivanjem izloenosti sistema i njegovih informacija kako unutranjim tako i sp oljanim opasnostima, 3) procenjivanjem odgovarajueg nivoa brige i za osetljivost i za iyloenost sistema. Svaka od ovih stavki opisana je detaljnije u daljem tekstu . 3.1.1 KRITINOST/OSETLJIVOST SISTEMA Kritinost/osetljivost sistema je mera vanosti i prirode informacija koje IT sistem obrauje. uva i prenosi na kritino, dnevno, po slovanje. Kritinost/osetljivost IT sistema i njegovih 28

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema informacija se moe oceniti analizom zahteva sistemu za privatnost, jedinstvenost i upotrebljivost. Privatnost sistema obezbeuje sigurnost da su informacije jednog IT sistema zatiene od pristupa neautorizovanih osoba, procesa ili ureaja. Integris anost sistema omoguava sigurnost da su informacije u jednom IT sistemu zatiene od n eautorizovane nepredviene ili nenamerne promene ili destrukcije. Integrisanost si stema je kvalitet IT sistema, koji se odnosi na korektnost logike sistema kao i pouzdanost operativnog sistema; logiku kompletnost hardvera i softvera koje su pr imenjeni u zatititnim mehanizmima; i konzistencijom strukture podataka pojavljiva nja uvanih podataka. Raspoloivost sistema obezbeuje da su informacije dostupne auto rizovanim korisnicima i/ili procesima vezanim za sistem u vremenu na pouzdanoj o snovi i da su zatieni od procedure odbijanja servisa. Sprovoenjem ovakve analize moe se odrediti vrednost jednog sistema. Ova vrednost je jedan od glavnih faktora u upravljanju rizikom. 3.1.2 IZLOENOST SISTEMA Izloenost sistema je mera mogueg rizi ka jednog IT sistema i od spoljanih i od unutranjih pretnji. Spoljanja izloenost sis tema odnosi se na metod kojim korisnik pristupa sistemu (na primer, odreena intra net veza, Internet veza, beina mrea), postojanje veze u pozadini sistema i za ta je taj sistem u pozadini jo povezan, kao i broj korisnika koji pristupaju sistemu. U nutranja izloenost sistema se odnosi na vrstu osoba koje imaju autorizaciju da pri stupe sistemu i informacijama koje se uvaju, obrauju i prenose korienjem sistema. Ov o ukljuuje stavke, kao to su obezbeenje sigurnosti u pozadini vezano za individualn i pristup, i/ili nivo dozvola, potvrda pristupa i obavetavanje ovlaenih. Sistem unu tranje izloenosti se razmatra za IT sisteme koji obrauju, uvaju ili prenose (klasifi kovane) informacije vezane za nacionalnu sigurnost ili (ne klasifikovane) osetlj ive informacije sa visokim zahtevima privatnosti. Ovo se, takoe, razmatra za IT s isteme sa visokim zahtevima integracije. Koncept izloenosti sistema i kako se on odnosi prema privatnosti, integrisanosti i dostupnosti u C&A procesima, bie detal jnije objanjen, kasnije u ovom podglavlju. 3.1.3 NIVO BEZBEDNOSTI Poverljivost, i ntegritet, i raspoloivost su vani faktori sigurnosti koje treba razmotriti kada se procenjuje celokupna sigurnost jednog IT sistema. Ovi faktori sigurnosti su opi sani u sekciji 3534(a)(1)(A) vladinog programa za reformu sigurnosti informacija u okviru nacionalnog zakona o autorizaciji u odbrani. Nivo brige o pouzdanosti je zasnovan na toleranciji za otkrivanje neautorizovanih ili kompromisnih inform acija o sistemu.14 Nivo Ukoliko se drugaije ne specificira, informacije u okviru saveznog sistema se obino nalaze u jednoj od dve kategorije: 1) osetljive informacije (neklasifikovane) i 2) informacije vezane za nacionalnu bezbednost (klasifikovane) Osetljive inform acije ukljuuju gubitak ma koje informacije, ne odgovarajuu upotrebu, ili neautoriz ovan pristupa ili izmenu, koja moe nepovoljno uticati na nacionalni interes, voenj e saveznih programa, ili privatnost na koju se pozivaju pojedinci u sekciji 5.5. 2a pod naslovom 5, US Code (Zakon o privatnosti iz 1974 godine), ali koji nije p osebno autorizovan po kriterijumima koji su uspostavljeni po Zakonu kongresa da se uva tajna u interesu nacionalne odbrane i spoljne politike. Neke specijalne ka tegorije osetljivih informacija se uvaju statutom, regulacijom ili ugovorom (na p rimer, privatne informacije, vlasnike informacije, informacije o upravljanju izvo zom, akademske informacije pre izdanja.). Iinformacije o 14 29

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema brige za integritet je zasnovan na toleranciji neautorizovanih izmena ili unitava nja informacija sistema. Nivo brige za raspoloivost je zasnovan na toleranciji kan jenja u obradi, prenosu, ili smetanju informacija u sistem ili toleranciji za oteen je ili odbijanje servisa, koje sistem treba da obezbedi. Kao to je opisano u NIST Specijalnoj Publikaciji 800-18, Vodi za razvoj planova sigurnosti za sisteme inf ormacionih tehnologija, kada se opisuje odgovarajui nivo brige, agencije treba da razmotre sve zakone, regulative, direktive, instrukcije, ili politike koje uspo stavljaju odreene zahteve za poverljivost, integritet ili raspoloivost podataka il i informacija sistema. Primeri mogu ukljuiti predsedniku odluku direktiva 63, zako n o privatnosti iz 1974, zakon o raunarskoj sigurnosti iz 1987, zakon o prenosivo sti i odgovornosti za informacije u zdravstvu, zakoni o tajnoj trgovini, patenti , zakon o autorskim pravima, federalni propisi o nabavci, ifre saveznih regulativ a, ili specifian statut ili regulativu koja se tie agencijskih podataka ili inform acija (npr porez ili informacija o popisu). Takoe, prvo treba razmotriti zahteve vizije. Agencija treba da izvriti procenu, kako bi se odredio nivo brige za siste m zasnovan na identifikaciji zahteva za poverljivost, integritet i raspoloivost. Vrednost nizak, srednji ili visok se zatim dodeljuju svakom faktoru. Tabela 3.1 moe posluiti agencijama kao upitstvo kako da dodele vrednosti za tajnost, integrit et i raspoloivost. Tabela 3.1 NIVOI BRIGE ZA KRITINOST / OSETLJIVOST SISTEMA NIZAK TAJNOST Osetljive informacija (neklasifikovane) Posledice neautorizovanog otkrivanja ili kompromitovanja podataka ili informacija u okviru nekog sistema su u osnovi pri hvatljive. Moe se oekivati da e gubitak tajnosti imati uticaja na interese na nivou agencije i da e imati neki negativan uticaj na izvrenje misije SREDNJI Posledice neautorizovanog otkrivanja ili kompromitovanja podataka ili informacij a u okviru nekog sistema su u osnovi retko prihvatljive. Moe se oekivati da e gubit ak tajnosti imati uticaja na interese na nivou agencije i da e imati neki negativ an uticaj na izvrenje misije ili stvoriti nesigurne uslove koji mogu rezultirati u povredama ili ozbiljnim tetama. Neprimenjivo VISOK Posledice neautorizovanog otkrivanja ili kompromitovanja podataka ili informacij a u okviru nekog sistema su ne prihvatljive. Moe se oekivati da e gubitak tajnosti imati nepovoljan uticaj na interese na nacionalnom nivou, spreiti izvrenje misije ili kreirati nesigurne uslove koji mogu rezultirati u gubitku ivota ili drugim iz uzetno tekim tetama. Posledice neautorizovanog otkrivanja TAJNOST Informacije bezbednosti, nacionalne Neprimenjivo ili nacionalnoj sigurnosti, ukljuuju ma koju informaciju koja je odreena shodno izvrnoj uredbi 1258 ili ma kojoj prethodnoj uredbi, ili uredbom o atomskoj energiji iz 1954, kao to je dodato da bi se obezbedila zatita od neautorizovanog pristupa , oz naeno je tako da ukazuje na njen klasifikovani status. Informacije nacionalne sig urnosti ukljuuju i osetljive informacije po odeljcima koje se odnose na ili su iz vodljive iz bezbednosnih izvora, metoda, ili analitikih procesa koji zahtevaju da budu voeni u okviru formalnog pristupa upravljakim sistemima, koje je uspostavio direktor centralne bezbednosti.

30

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema kompromitovanja podataka ili informacija u okviru nekog sistema su ne prihvatljive. Moe se oekivat i da e gubitak tajnosti izazvati izuzetno teke i ozbiljne tete, ili tete po nacional noj bezbednosti. Posledice neautorizovanog otkrivanja ili kompromitovanja podata ka ili informacija u okviru nekog sistema su ne prihvatljive. Moe se oekivati da e gubitak integriteta imati nepovoljan uticaj na interese na nacialnom nivou, sprei ti izvrenje misije ili kreirati nesigurne uslove koji mogu rezultirati u gubitku i vota ili drugim izuzetno tekim tetama. Posledice neautorizovanog otkrivanja ili ko mpromitovanja podataka ili informacija u okviru nekog sistema su ne prihvatljive . Moe se oekivati da e gubitak raspoloivosti imati nepovoljan uticaj na interese na nacionalnom nivou, sreiti izvrenje misije ili kreirati nesigurne uslove koji mogu rezultirati u gubitku ivota ili drugim izuzetno tekim tetama. (klasifikovane) INTEGRITET Posledice neautorizovanog otkrivanja ili kompromitovanja podataka ili informacij a u okviru nekog sistema su u osnovi prihvatljive. Moe se oekivati da e gubitak int egriteta imati uticaja na interese na nivou agencije i da e imati neki negativan uticaj na izvrenje misije. RASPOLOIVOST Posledice neautorizovanog otkrivanja ili kompromitovanja podataka ili informacija u okviru nekog sistema su u osnovi prihvatljive. Moe se oekivati da e gubitak raspoloivosti imati uticaja na interese na nivou agencije i da e imati neki negativan uticaj na izvrenje misije. Posledice neautorizovanog otkrivanja ili kompromitovanja podataka ili informacij a u okviru nekog sistema su u osnovi retko prihvatljive. Moe se oekivati da e gubit ak integriteta imati nepovoljan uticaj na interese na nivou agencije, i da e imat i neki negativan uticaj na izvrenje misije ili stvoriti nesigurne uslove koji mog u rezultirati u povredama ili ozbiljnim tetama. Posledice neautorizovanog otkriva nja ili kompromitovanja podataka ili informacija u okviru nekog sistema su u osn ovi retko prihvatljive. Moe se oekivati da e gubitak raspoloivosti imati nepovoljan uticaj na interese na nivou agencije i da e imati neki negativan uticaj na izvrenj e misije ili stvoriti nesigurne uslove koji mogu rezultirati u povredama ili ozb iljnim tetama. 3.1.3.1 Spoljna izloenost sistema Pored definisanja nivoa brige za tajnost, integ ritet i raspoloivost, mora se obratiti panja i na definisanje nivoa brige za unutr anje i spoljno izlaganje sistema. Treba razmotriti potencijalnu izloenost IT siste ma spoljnjim pretnjama uzimajui u obzir sledee faktore 31

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema spoljnje izloenosti: 1) metod pristupa 2) pozadinske konekcije i 3) broj autorizo vanih korisnika. Treba dodeliti nivo vrednosti zabrinutosti, (nizak, srednji ili visok) za svaku od oznaenih faktora spoljne izloenosti. Nivo zabrinutosti za ekst ernu izloenost sistema je najvea vrednost u odnosu na vrednosti dodeljene svakom o d pojedinih faktora izloenosti. Na primer, sistem sa visokim nivoom za metod pris tupa, niskim nivoom za pozadinske konekcije i niskim nivoom za broj autorizovnih korisnika imao bi visok nivo za spoljnju izloenost sistema. Tabela 3. 2 NIVOI BRIGE ZA SPOLJNJU IZLOENOST METOD PRISTUPA NIZAK SREDNJI Pristup sistemu je kroz zatiene komunikacione kanale, (na primer, iznajmljene lini je) Pristup sistemu je kroz relativno ograniene komunikacione kanale (na primer, intranet konekcije) POZADINSKE KONEKCIJE Ne postoje konekcije u pozadini prema bilo kom sistemu. Pozadinske konekcije pre ma sistemu postoje, i to su sistemi koji su relativno ogranieno povezani sa drugi m sistemima (na primer, intranet konekcije) Pozadinske konekcije prema sistemu p ostoje i to su sistemi koji su otvoreno povezani za druge sisteme (na primer, In ternet, beine mree) BROJ KORISNIKA Vrlo limitiran broj ovlaenih korisnika ima pristup sistemu. Limitiran broj ovlaenih korisnika ima pristup sistemu. VISOK Pristup sistemu je kroz komunikacione kanale sa slobodnim pristupom (na primer, Internet ili beine mree) Neogranieni broj korisnika ima pristup sistemu (na primer, javni kiosk) 3.1.3.2 Unutranja izloenost sistema Unutranja izloenost sistema bi trebala da se raz matra samo za sisteme koji imaju visok nivo tajnosti. Treba razmotriti potencija lne izloenosti IT sistema unutranjim pretnjama, (npr. osobe bez odgovarajue opte pov erljivosti obzirom na zatitu, i/ili dozvola za to, potvrde za pristup, i/ili potr ebe za znanjem tajnih podataka, mogu da pristupe krajnje osetljivim (neklasifiko vanim) informacijama, ili (klasifikovanim) informacijama u vezi nacionalne sigur nosti. 15 Da bi se definisao odgovarajui nivo unutranje izloenosti sistema, treba s e referisati na tabelu 3.3. U njoj su data 4 sluaja koja karakteriu mogua stanja si stema u Koncepti dozvola, potvrda prava pristupa i potrebe da se saznaju tajni podaci su u optem sluaju pridrueni sistemima i informacijama od nacionalne vanosti i tajnosti (klasificiranim). Ipak, agencije koje obrauju, uvaju i prenose visoko osetljive i neklasifikovane informacije, (na primer, informacije koje imaju visok nivo tajn osti) e upotrebiti koncepte analogne ovima koji se koriste za klasifikovano okruen ju. Treba primetiti da se korienje rei dozvola u ovoj specijalnoj publikaciji odnosi ili na proveru individualnog pozadinskog pristupa u odnosu za bezbednost (poneka d se naziva bezbednosna provera) ili na zvaninu bezbednosnu dozvolu (kao to se to radi za pristup klasifikovanim informacijama) Na primer,od rukovodilacai sistema u vanim, saveznim neklasifikovanim sistemima se zahteva da prou optu proveru (iako nema potrebe za pristup klasifikovanim informacijama) zbog potencijalne mogunost i da nakode operacijama agenciji. 15 32

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema odnosu na autorizovane korisnike i informacije kojima se pristupa. Treba izabrat i sluaj koji na najbolji nain opisuje stanje vaeg sistema. Odgovarajua vrednost (t.j . niska, srednja ili visoka) moe biti dodeljena s obzirom na stepen zabrinutosti za unutranju izloenost tog sistema. Na primer, ako svi korisnici sa pristupom obra di, uvanju ili prenoenju informacija (klasifikovane) od nacionalne bezbednosti i v anosti ili visoko osetljivih (neklasifikovanih) informacija imaju odgovarajue potv rde i provere u odnosu na sigurnost i bezbednost kao i formalno date dozvole pri stupa i nivo potrebe sa saznanjem tajnih podataka, to bi se odnosilo na sluaj bro j 1, i uslovilo bi nizak nivo interne izloenosti. Tabela 3.3 NIVOI BRIGE ZA UNUTRANJU IZLOENOST DOZVOLA NISKA SLUAJ 1 Svaki korisnik ima dozvolu za sve informacije koje se obrauju, memoriu ili prenose od strane sistema. Svaki korisnik ima dozvolu za sve informacije koje se obrauju, memoriu ili prenose od strane sistema. Svaki korisnik ima dozvolu za vein u osetljivih informacija koje se obrauju, memoriu ili prenose od strane sistema. N eki korisnici nemaju dozvolu za sve informacije koje se obrauju, memoriu ili preno se od strane sistema. Svaki korisnik ima dozvolu za one informacije kojima treba da pristupi. ODOBRENJE PRISTUPA Svaki korisnik ima odobrenje pristupa za sve informacije koje se obrauju, memoriu ili prenose od strane sistema. Svaki korisnik ima odobrenje pristupa za sve info rmacije koje se obrauju, memoriu ili prenose od strane sistema. Svaki korisnik ima odobrenje pristupa samo za informacije kojima treba da pristupi. Svaki korisnik ima odobrenje pristupa samo za informacije kojima treba da pristupi. AUTORIZACIJA ZNANJA PO NIVOU POTREBE Svaki korisnik ima odgovarajuu autorizaciju znanja za sve informacije koje se obr auju, memoriu ili prenose od strane sistema. Svaki korisnik ima odgovarajuu autoriz aciju znanja za neke informacije koje se obrauju, memoriu ili prenose od strane si stema. Svaki korisnik ima odgovarajuu autorizaciju znanja samo za informacije koj ima treba da pristupi. Svaki korisnik ima odgovarajuu autorizaciju znanja samo za informacije kojima treba da pristupi. SREDNJI SLUAJ 2 SREDNJI SLUAJ 3 VISOK SLUAJ 4 3.2 Kontrole sigurnosti Kontrole sigurnosti su ukljuene u dodatnoj publikaciji NIST, Specijalna publikaci ja 800-53, Minimalne kontrole sigurnosti za savezne IT sisteme, (planirano za pr olee 2003) odvojeno 33

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema

od opisa procesa sertifikacije i autorizacije s obzirom da e taj skup kontrola vr emenski evoluirati kako se menja tehnologija i identifikuju nove zatite za IT sis teme. Sledee sekcije opisuju 1) organizaciju kontrole sigurnosti i konvencije ime novanja 2) proces selekcije kontrole sigurnosti 3) proces prilagoavanja kontrola sigurnosti zasnovan na odlukama donetim na proceni rizika u okviru agencije. 3.2 .1 ORGANIZACIJA KONTROLA SIGURNOSTI Radi lakeg korienja, kontrole sigurnosti su u S pecijalnoj publikaciji 800-53 organizovane u klase i familije, Postoje tri opte k lase kontrola sigurnosti (t.j. upravljaka, operativna, i tehnika) koje odgovaraju glavnim sekcijama plana bezbednosti definisanog u NIST Specijalnoj publikaciji 8 00-18. U svakoj od ovih klasa su definisane specifine familije koje pokrivaju sle dee opte oblasti: upravljanje rizikom, razvoj i izgradnju sistema, upravljanje kon figuracijom sistemske interkonekcije, lino obezbeenje, saznanje edukacija i obuka iz oblasti sigurnosti, fizika zatita i zatita sredine, zatita medijuma, planiranje n epredvienih situacija, odravanja sistemskog softvera i hardvera, integritet sistem a i podataka, dokumentacija sposobnost odgovorna na incidente, identifikacija i autentikacija, logiki pristup, praenje i komunikacije. Kontrole sigurnosti su grup isane u familije na osnovu kritinih elemenata. Kritini elementi, kao to je to objanj eno u NIST specijalnoj publikaciji 800-26, Vodi za samostalnu izgradnju sigurnost i IT sistema, predstavljaju vano polje u odnosu na zatitu sistema pa za svaki krit iki element imamo jednu ili vie kontrola sigurnosti. Na primer, kritiki element u f amiliji indentifikacije i autentikacije glasi: korisnici se individualno autentif ikuju kroz ifre, tokene ili druge ureaje. Nekoliko kontrola sigurnosti u familiji i dentifikacije i autentifikacije se pridodaju ovom kritikom elementu. Ove podkontr ole moraju biti prikazane i korektno implementirane,a dovoljno efikasne, da demo nstriraju da je taj kritiki element zadovoljen. Jedinstvena konvencija davanja im ena za kontrole sigurnosti se upotrebljava da bi se pomoglo opisu, u kratkoj for mi, familije iz koje je kontrola izabrana i da bi se dodelio broj kontrole u okv iru familije. Za kontrole (koje podravaju visoke nivoe tajnosti, integriteta i ra spoloivosti), a koje su planirane za ukljuivanje u dodatnom paketu mera, mogu se k oristiti dodatna obleja, kao ekstenzije osnovnih imena. Nivo odgovarajueg obeleja u kazuje na to da je M za srednji nivo, ili H za visok. Obeleje za faktor sigurnosti uk azuje C za tajnost I za integritet i / ili A za raspoloivost. Na primer, kontrola sigu nosti identifikovana kao PS-8 oznaava da je kontrola iz familije individualne sig urnosti (personal security) i da je osma takva kontrola u okviru te familije. Mn ogo sloenija kontrola iz iste familije, PS-8.MCIA, je odgovarajue za sisteme koji zahtevaju srednji nivo tajnosti, integriteta, i raspoloivosti. U drugom primeru k ontrola sigurnosti za oznakom LA-16.HCI oznaava kontrolu iz familije logikog prist upa (esnaesta kontrola u okviru te familije) da je ona odgovarajua za sisteme koji zahtevaju visok nivo tajnosti i integriteta. Po definiciji, kontrole sigurnosti koje ne podravaju visok nivo sigurnosti, sadrane su u standardnom paketu i ne kor iste dodatna obeleja, poto jer su sve kontrole primenljive na osnovne nivoe sistem a tajnosti, integriteta i raspoloivosti. Slika 3.1 ilustruje konvenciju imenovanj a kontrola sigurnosti i osnovne sekcije nomenklature. 34

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Slika 3.1 Konvencije imenovanja za kontrole sigurnosti 3.2.2. IZBOR KONTROLA BEZ BEDNOSTI Poto su specifini nivoi za tajnost, integritet, i raspoloivost kao i izloen ost sistema odreeni, odgovarajue kontrole sigurnostise mogu birati iz skupa pre-de finisanih kontrola koje su date u NIST Specijalnoj publikaciji 800-53, Minimalne kontrole sigurnosti za savezne IT sisteme (planirano za prolee 2003). Kontrole s adrane u toj specijalnoj publikaciji su minimalni skup, preporuen za savezne siste me koji zahtevaju osnovne, srednje ili visoke nivoe sigurnosti u oblasti tajnost i, integriteta i raspoloivosti. Kada druga nacionalna, agencijska ili dokumenta n a nivou komponente, propiu zahteve u odnosu na bezbednost IT sistema koja nije ad ekvatno pokrivena ili vie restriktivna u odnosu na primenu kontrola sigurnosti na vedenih u NIST Specijalnoj publikaciji 800-53, sistemu kontrola zatita izabranom za taj pojedini IT sistem moraju biti dodate dodatne kontrole, koje odgovaraju t im zahtevima potujui sertifikaciju i akreditaciju. Proces izbara odgovarajuih kontr ola sigurnosti se po pravilu postie u tri koraka: 1) selekcija kontrola sigurnost i iz standardnog paketa, 2) formiranje specijalizovanog skupa dodatnih kontrola sigurnosti baziranih na datim visokim nivoima u odnosu na tajnost, integritet i raspoloivost i 3) dodavanje agencijskih posebnih kontrola sigurnosti ili kontrola voenih tehnologijom kontrola sigurnosti. Standardni paket kontrola sigurnosti sa dri osnovne kontrole za tajnost, integritet i raspoloivost. Ovo je osnovni skup ko ntrola sigurnosti, koji bi morao biti primenjen u svim saveznim IT sistemima. Pot o se izabere standardni paket kontrola sigurnosti, neophodno je istraiti nivoe br ige za tajnost, integritet i raspoloivost u cilju odreivanja potrebe za uvoenje dod atnih kontrola za sistem, u okviru dodatnog paketa mera sigurnosti. Treba uradit i paljivu analizu postojeih dodatnih kontrola iz NIST specijalne publikacije 800-5 3, da bi se izabrale odgovarajue kontrole sigurnosti za dodatni paket. Da bi se o sigurala kompletnost u procesu analize i odabira, trebalo bi da istraiti svaku fa miliju u okviru upravljake operativne klase kontrola. Na primer, neka agencija sa srednjim nivoom zabrinutosti za tajnost, visokim nivoom za integritet i niskim nivoom za raspoloivost. (t.j. C=M, I=H, A=L), izabrala bi standardni paket osnovn ih kontrola i onda prola kroz svaku familiju radi kontrola koje mogu biti primenj ene sa nekom od sledeih ekstenzija u odnosu 35

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema na osnovno kontrolno ime: MC, MCI, MCA, MCIA, HI, HCI, HIA, HCIA. Ovaj proces os igurava odabir odgovarajue kontrole sigurnosti u okviru dodatnog paketa, za sredn ji ili vii nivo tajnosti ili integriteta. Kontrole za nii nivo raspoloivosti su pok rivene u standardnom paketu osnovnih kontrola. Slika 3.2 ilustruje proces odabir a kontrola sigurnosti za standardne i dodatne pakete. Slika 3.2 Izbor kontrola sigurnosti Dokumentovani nivoi brige za internu i ekste rnu izloenost sistema, mogu imati odreeni efekat na nivoe sertifikacije izabran za sistem i takoe, mogu obezbediti opravdanje za zamenu (uz dozvolu rukovodioca) ek vivalentnih kontrola ili dozvolu za odustajanje od nekih izabranih kontrola sigu rnosti. Efekat interne ili eksterne izloenosti sistema na nivo sertifikacija ili odabrane kontrole sigurnosti, je opisan u sekcijama 3.2.3 i 3.3.5. 3.2.3 PODEAVAN JE IZBORA KONTROLA SIGURNOSTI Mogu se dogoditi situacije, kada rukovodstvo donos i odluku na bazi poznavanja rizika, da zameni ekvivalentne kontrole, odustane od odgovarajue kontrole ili pobolja preporuene kontrole sigurnosti za neki IT sistem. Na primer, rukovodstvo moe dozvoliti zamenu ekvivalentnih kontrola sigurnosti, u koliko za to postoje razlozi operativne prirode, trokovi ili drugi razlozi (obezb eujui postizanje ciljeva sigurnosti). Zamena ekvivalentnih kontrola dozvoljena od strane rukovodstva, mora biti dokumentovana u planu sigurnosti. Rukovodstvo moe i odustati od neke odreene kontrole sigurnosti, jer korist (bar privremena) pri ra du bez tih kontrola, moe biti vanija od rizika ekanja na implementaciju potpune kon trole. Ako su odreene kontrole sigurnosti izostavljene, to mora biti zabeleeno u p lanu sigurnosti sa kompletnim obrazloenjem i dokumentacijom o stepenu kompenzacij e za izostavljene kontrole sigurnosti. Suprotno tome, moe biti sluajeva kada rukov odstvo implementira mnogo jae kontrole sigurnosti onih koje su sadrane u standardn im ili dodatnim paketima. Ovo takoe treba da bude dokumentovano u planu sigurnost i. 36

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Da bi bolje ilustrovali proces izostavljanja kontrola, imamo sledei primer. Neka agencija koja ima visok nivo brige za tajnost s obzirom na kritinost/osetljivost informacija koje se obrauju, uvaju ili prenose, agencija e inicijalno izabrati kont role sigurnosti za visoku tajnost iz NIST Specijalne publikacije 800-53. U proce su dalje analize, ta agencija definie nivo brige i za unutranju i za spoljanju izloe nost sistema kao nisku (tj. sistem nema eksternih mrenih konekcija i sistem je lo ciran u vrlo zatienim prostorijama sa uvarima i perimetarskom zatitom i svi zaposlen i koji pristupaju sistemu imaju odgovarajue autorizacije). Izabrane tehnike kontro le. ukljuujui i stroge kontrole pristupa operativnom sistemu i odreene kontrole ifri ranja sadrane u dodatnom paketu, mogu, po diskrecionom pravu rukovodstva biti izo stavljane ali uz pretpostavku da postoje kontrole sigurnosti koje ih zamenjuju ( t.j. upravljake i operacione kontrole) koje obezbeuju potrebnu zatitu sistema da bi se preostali rizik zadrao u okviru prihvatljivog opsega. 3.2.4 KRATAK PREGLED IZ BORA KONTROLA SIGURNOSTI Ukratko, izbor odgovarajuih kontrola sigurnosti za neki IT sistem je proces od tri koraka KORAK 1: KARAKTERIZACIJA SISTEMA Iz plana sigu rnosti treba uzeti sledee informacije koje se odnose na sistem: Granice akreditac ije za sistem i ako je pogodno predloenu dekompoziciju sistema na podsistemske ko mponente Kritinost/osetljivost sistema (ili podsistema ukoliko je tako bolje) baz irana na nivoima brige za tajnosti, integritetu i raspoloivost. [Tabela 3.1] Spol jnju izloenost sistema na osnovu nivoa brige za sistem ili podsistem, ako to odgo vara [Tabla 3.2] Unutranju izloenost sistema na osnovu nivoa brige za sistem ili p odsistem, ako je to pogodnije [Tabla 3.3] KORAK 2: ODABIR MINIMALNE ODGOVARAJUE K ONTROLE SIGURNOSTI ZA DATI SISTEM Izabrati minimalne kontrole sigurnosti iz stan dardnog paketa za osnovne kontrole (obavezno za sve sisteme.) [NIST Specijalna P ublikacija 800-53] Izabrati dodatne minimalne kontrole sigurnosti (srednji ili v ii nivoi) ako je pogodno, da bi se kreirao dodatni paket kontrola zasnovan na uvea nim nivoima brige za tajnost, integritet, i / ili raspoloivost. [NIST Specijalna Publikacija 800-53] KORAK 3: PRILAGOENJE KONTROLA SIGURNOSTI ZASNOVANE NA ODLUKAM A O IZLOENOSTI SISTEMA I RIZIK Prilagoditi izabrane kontrole sigurnosti, bazirane na unutranjoj i spoljnoj izloenosti i odlukama baziranim u odnosu na rizik; Opisa ti kontrole od kojih se odustalo i priloiti dokumentaciju o tome. 3.3 Nivoi sertifikacije sigurnosti 37

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Osnovni namena procesa serttifikacije je da se odredi da li su kontrole sigurnos ti jednog IT sistema korektno implementirane i da li su efektivne u svojoj prime ni. Tana i efikasna primena ovih kontrola obezbeuje osiguranje da e zahtevi za zatit u sistema biti zadovoljeni. Da bi se odredila tanost i efikasnost kontrole sigurn osti, postoje mnoge tehnike verifikacije koje se mogu upotrebiti tokom sertifika cije i akreditacije. Ove tehnike sadre: Intervjuisanje zaposlenih u agenciji koji imaju veze sa aspektima sigurnosti tog sistema; Pregled i analiza politika u ve zi sa bezbednou, procedura i dokumentacije Posmatranje operacije i aktivnosti koje se odnose na zatitu; Analiziranje, testiranje i procena relevantnosti sigurnosti i kritinih aspekata sistemskog hardvera, softvera, firmvera i operacija u odnosu na zatita; i Demonstracije ponaanja i vebe Postoje tri nivoa sertifikacije, koji s u definisani u ovoj specijalnoj publikaciji: Nivo jedan sertifikacije sigurnosti (SLC-1), Nivo dva sertifikacije sigurnosti (SLC-2) i nivo tri sertifikacije sig urnosti (SLC-3). Svaki od ovih nivoa dodatno doprinosi intenzitetu i strogosti u primeni tehnika verifikacije da bi se odredila usaglaenost sa zahtevima sigurnos ti i da bi se pokazala tanost i efikasnost kontrola sigurnosti. Sledee sekcije opi suju nivoe sertifikacije i tehnike verifikacije u odnosu na te nivoe. 3.3.1 SERT IFIKACIJA SIGURNOSTI NIVO 1 (SCL-1) SLC-1 je ulazni nivo sertifikacije za IT sis teme. Ovaj nivo sertifikacije je odgovarajui za sisteme koji zahtevaju niske nivo e brige za tajnost, integritet i raspoloivost. On je takoe odgovarajui, po diskreci onom pravu rukovodstva, za sisteme sa srednjim do visokim nivoima brige za tajno st, integritet i/ili raspoloivost i niskim do srednjim nivoima brige za izloenost sistema (npr za sisteme koji rade u okruenju nieg ili srednjeg rizika). SLC-1 sert ifikacije su tipino agencijski voene, sa nezavesnom procenom ili osnovnim izvetajim a o bezbednosti IT sistema korienjem upitnika ili specijalizovanih kontrolnih list a. Ove procene se rade sa namerom da na relativno niskom nivou demonstriraju da su kontrole sigurnosti za IT sisteme korektno implementirane i efikasne u svojoj primeni. SCL-1 sertifikacije ne zahtevaju visok nivo napora i mogu se kompletir ati sa minimalnim resursima, korienjem jednostavnih tehnika verifikacije, kao to je intervjuisanje zaposlenih, pregled dokumentacije i posmatranje. 3.3.2 SERTIFIKA CIJA SIGURNOSTI NIVO 2 (SCL-2) SLC-2 je sertifikacija srednjeg nivoa za IT siste me. Ovaj nivo sertifikacije je odgovarajui za sisteme koji rade u okruenju srednji h rizika brige za tajnost, integritet i raspoloivost. On je takoe odgovarajui, po d iskrecionom pravu rukovodstva, za sisteme sa visokim nivoima brige za tajnost, i ntegritet i/ili raspoloivost i niskim do srednjim nivoima brige za izloenost siste ma (npr za sisteme koji rade u okruenju nieg ili srednjeg rizika). SLC-2 sertifika cije se pozivaju na nezavisne procene izgradnje IT sistema bazirane na tehnikama vertifikacije i procedurama iz SLC-1 uz dodatak malo ozbiljnijih tehnika ili pr ocedure, ukoliko je to potrebno. Ove nezavisne procene su zamiljene da demonstrir aju na srednjem nivou 38

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema sigurnosti, da su kontrole sigurnosti korektno implementirane i efikasne u svojo j primeni. SLC-2 sertifikacije zahtevaju srednji nivo napora da bi se kompletira le sa ogranienim do srednjim resursima, koristei standardne komercijalno raspoloive alatke za procenu, i verifikacione tehnike kao to su intervjuisanje zaposlenih, pregled dokumentacije i posmatranje, demonstracije ograniene aktivnosti testiranj a i procene sigurnosti, (na primer, ogranieno funkcionalno testiranje, regresivna analiza i testiranje, testiranje mogueg proboja) 3.3.3 SERTIFIKACIJA SIGURNOSTI NIVO 3 (SCL-3) SCL-3 je sertifikacija najvieg nivoa za IT sisteme. Ovaj nivo sert ifikacije je odgovarajui za sisteme koji zahtevaju visok nivo brige za tajnost, i ntegritet i raspoloivost. SLC-3 sertifikacija se pozivaju na nezavisne procene iz gradnje IT sistema, bazirane na tehnikama vertifikacije i procedurama iz SLC-1 i SLC-2 i koriste najrigoroznije tehnike verifikacije koje su raspoloive. Ovi neza visne procene su zamiljenie da pokazu, na visokom nivou sigurnosti, da su kontrol e sigurnosti za IT sisteme korektno implementirane i efikasne u svojoj primeni. SCL-3 sertifikacije zahtevaju visok nivo napora da bi se kompletirale, uz korienje znaajnih resursa i upotrebu najsloenijih alata za procenu i tehnike verifikacije (t.j. analiza izgradnje sistema, proireno funkcionalno testiranje sa analizom, re gresivna analiza i testiranje, demonstracije, vebe i testiranje proboja sa opcijo m postavke Crvenog Tima. Tabela 3.4 sumira razliite tehnike verifikacije u odnosu n a nivo sertifikacije. Tabela 3.4 NIVOI SERTIFIKACIJE I TEHNIKE VERIFIKACIJE SCL SCL 3 SCL 2 SCL 1 TEHNIKE VERIFIKACIJE Visok intenzitet, baziran na vebama, nezavisna procena Anali za projektovanja sistema Funkcionalno testiranje sa analizom pokrivenosti Regres ionalna analiza i regresiono testiranje Testiranje proboja (opciono Crveni tim) Demonstracije i vebe za proveru korektnosti i efikasnosti kontrola sigurnosti SCL -1 i SCL-2 tehnike verifikacije (ukoliko je odgovarajue) Srednji intenzitet, bazi ran na demonstraciji, nezavisna procena Funkcionalno testiranje Regresionalna an aliza i regresiono testiranje Testiranje proboja (opciono) Demonstracije i vebe z a proveru korektnosti i efikasnosti kontrola sigurnosti SCL-1 tehnike verifikaci je (ukoliko je odgovarajue) Nizak intenzitet, baziran na kontroli, nezavisni preg led sigurnosti Intervju personala Pregled politika sigurnosti, procedura, dokume nata vezanih za sistem Posmatranje operacija sistema i kontrola sigurnosti 39

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 3.3.4 IZBOR NIVOA SERTIFIKACIJE Poto su odreeni nivoi brige za tajnost, integritet , i / ili raspoloivost, moe se izabrati poetni nivo sertfikacije. Ako je bilo koji nivo brige za tajnost, integritet, ili raspoloivost visok, onda se za nivo sertif ikacije bira nivo 3 (SCL-3). Ako nema visokih nivoa brige i ako je bilo koji niv o brige za tajnost, integritet, i raspoloivost srednji, onda se bira nivo sertifi kacije 2 (SCL-2). Ako su svi nivoi brige za tajnost, integritet, i raspoloivost n iski, onda se bira nivo sertifikacije 1 (SCL-1) Jednom kada je inicijalni nivo s ertifikacije odabran, nivo se moe podeavati s obzirom na nivo brige za izloenost si stema, da bi se dobio stvarni nivo od sertifikacije. Ako je nivo brige za tajnos t nizak ili srednji, spoljna izloenost sistema uzima u obzir pri moguem doterivanj u inicijalnog nivoa sertifikacije. Ako je nivo brige za eksternu izloenost sistem a visok, onda nikakva podeavanja nivoa sertifikacija nisu potrebne. Ako je nivo e ksterne izloenosti sistema srednji, onda inicijali nivo sertifikacije moe biti sma njen za jedan nivo, uz dozvolu upravljaa. (na primer, SCL-3 se smanjuje na SCL-2, ili SCL-2 se smanjuje na SCL-1) Ako je nivo brige za spoljnju izlaenost sistema nizak onda inicijani nivo sertifikacije moe biti smanjen do dva nivoa uz dozvolu upravljaa (SCL-3 moe biti smanjen na SCL-2 ili SCL-1, SCL-2 na SCL-1). Ako je nivo brige za tajnost visok, onda se razmatraju i spoljana i unutranja izloenost sistem a da bi se napravile potrebne izmene u inicijalnom nivou sertifikacije. Da bi se definisala totalna izloenost sistema, treba konsultovati tabelu 3.5. Treba nai od govarajui red u tabeli koji se odnosi na odgovarajui nivo spoljne i unutranje izloen osti sistema onda dobiti nivo brige za totalnu izloenost sistema iz zadnje kolone tog reda. Tabela 3.5 ODREIVANJE TOTALNE IZLOENOSTI SISTEMA SPOLJNJA IZLOENOST SISTEMA NISKA NISKA NISKA SREDNJA SREDNJA SREDNJA VISOKA VISOKA VISOKA UNUTRANJA IZLOENOST SISTEMA NISKA SREDNJA VISOKA NISKA SREDNJA VISOKA NISKA SREDNJA VISOKA TOTALNA IZLOENOST SISTEMA NISKA SREDNJA VISOKA SREDNJA SREDNJA VISOKA VISOKA VISOKA VISOKA Ako je nivo brige za totalnu izloenost sistema visok, onda nisu potrebne nikakve promene inicijalnog nivoa sertifikacije. Ako je nivo brige za totalnu izloenost s istema srednji, onda inicijalni nivo sertifikacije moe biti umanjen za jedan nivo uz dozvolu rukovodstva (na primer, SCL-3 se smanjuje na SCL-2 ili se SCL-2 sman juje na SCL-1) Ako je nivo brige za totalnu izloenost sistema nizak, onda inicija lni nivo sertifikacije moe biti umanjen za dva nivoa uz dozvolu rukovodstva, (na primer, SCL-3 se smanjuje na SCL-2 ili SCL-1 a SCL-2 se smanjuje na SCL-1) 40

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 3.3.5 KRATAK PREGLED IZBORA NIVOA SERTIFIKACIJE Ukratko, biranje nivoa sertifika cije za odreeni IT sistem je proces od tri koraka: KORAK 1: Opisivanje sistema Po trebno je dobaviti sledee informacije u odnosu na sistem iz plana sigurnosti: Ogr anienja akreditacija za sistem i, ukoliko je odgovarajue, predloena dekompozicija s istema na podsisteme. Kritinost / osetljivost tog sistema (ili podsistema ako je odgovarajue) bazirana na nivoima brige za tajnost, integritet i raspoloivost. [Tab ela 3.1] Spoljna izloenost sistema bazirana na nivou brige za sistem ili podsiste m ako je odgovarajue. [Tabela 3.2] Unutranja izloenost sistema (samo tajnost) bazir ana na nivo brige za sistem ili podsistem ako je odgovarajue. . [Tabela 3.3] KORA K 2: Izbor odgovarajueg inicijalnog nivoa sertifikacije i sigurnosti za dotini sis tem Ako je bilo koji nivo brige za tajnost, integritet, ili raspoloivost = VISOK Onda izabrati SCL-3 Inae Ako je bilo koji nivo brige za tajnost, integritet, ili raspoloivost = SREDNJI Onda izabrati SCL-2 Inae Ako su svi nivoi brige za tajnost, integritet, ili raspoloivost = NIZAK Onda izabrati SCL-1 KORAK 3: Podeavanje nivo a sertifikacija sigurnosti bazirano na izloenosti sistema. Ako je nivo brige tajn ost i / ili integritet = VISOK Onda idi direktno na KORAK 3B Inae Idi na KORAK 3A i preskoi KORAK 3B. KORAK 3A: Razmotri spoljnju izloenost radi podeavanja nivoa se rtifikacija. Ako je nivo brige za spoljnju izloenost sistema = VISOK Onda nikakva podeavanja nivoa sertifikacija nisu potrebne Inae Ako je nivo brige tajnost i / i li integritet = SREDNJI i ako je inicijalni nivo sertifikacije iz KORAK 3 = SCL3 Onda razmatranje mogunosti nivoa sertifikacije na SCL-2 uz dozvolu upravljaa Inae Ako je nivo brige tajnost i / ili integritet = SREDNJI i ako je inicijalni nivo sertifikacije iz KORAK 3 = SCL-2 Onda razmatranje mogunosti nivoa sertifikacije na SCL-1 uz dozvolu upravljaa Inae 41

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Ako je nivo brige tajnost i / ili integritet = NIZAK i ako je inicijalni nivo se rtifikacije iz KORAK 3 = SCL-3 Onda razmatranje mogunosti nivoa sertifikacije na SCL-2 ili SCL-1 uz dozvolu upravljaa Inae Ako je nivo brige tajnost i / ili integr itet = NIZAK i ako je inicijalni nivo sertifikacije iz KORAK 3 = SCL-2 Onda razm atranje mogunosti nivoa sertifikacije na SCL-1 uz dozvolu upravljaa KORAK 3B: Razmotri internu i eksternu izloenost radi podeavanja nivoa sertifikacij a. Konsultuj tabelu 3.5 radi odreivanja nivoa brige za totalnu izloenost sistema; nai odgovarajui red u tabeli koji se odnosi na nivo izloenosti za spoljnju i unutran ju izloenost sistema onda preuzmi nivo brige za totalnu izloenost sistema iz zadnj e kolone u tom redu. Ako je nivo brige za totalnu iloenost sistema = VISOK Onda n ikakva podeavanja nivoa sertifikacija nisu potrebna Inae Ako je nivo brige za tota lnu iloenost sistema = SREDNJI I ako je inicijalni nivo sertifikacije iz KORAK 3 = SCL-3 Onda razmatranje mogunosti nivoa sertifikacije na SCL-2 uz dozvolu upravl jaa Inae Ako je nivo brige za totalnu iloenost sistema = SREDNJI I ako je inicijaln i nivo sertifikacije iz KORAK 3 = SCL-2 Onda razmatranje mogunosti nivoa sertifik acije na SCL-1 uz dozvolu upravljaa Inae Ako je nivo brige za totalnu iloenost sist ema = NIZAK I ako je inicijalni nivo sertifikacije iz KORAK 3 = SCL-3 Onda razma tranje mogunosti nivoa sertifikacije na SCL-2 ili SCL-1 uz dozvolu upravljaa Inae A ko je nivo brige za totalnu iloenost sistema = NIZAK I ako je inicijalni nivo ser tifikacije iz KORAK 3 = SCL-2 Onda razmatranje mogunosti nivoa sertifikacije na S CL-1 uz dozvolu upravljaa Smanjivanje nivoa sertifikiacije, posle paljivog razmatr anja spoljnje i unutranje izloenosti sistema, je odluka bazirana na proceni rizika koju moe doneti rukovodstvo. Razmotrimo sledee primere: Primer 1: Federalni IT si stem obrauje, smeta i prenosi informacije za kljunu finansijsku aplikaciju. Agencij a odgovorna za sistem odreuje da je nivo brige za integritet visok, a da su nivoi brige za tajnost i raspoloivost srednji. Agencija takoe odreuje da je nivo brige z a spoljnu izloenost sistema srednji s obzirom na injenicu da je pristup finansijsk om sistemu 42

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema kroz relativno limitirane komunikacione kanale, (t.j. intranet konekcija) i nema konekcija u pozadini prema sistemu, a broj korisnika je relativno mali (poveren samo lanovima osoblja u odeljku odgovornom za aplikaciju). Interna izloenost sist ema nije razmatrana poto nivo za tajnost nije visok. S obzirom na gornje informac ije, za sistem su definisani standardni paket kontrole sigurnosti i dodatni pake t kontrola za srednju tajnost, visoki integritet, i srednju raspoloivost. Visok n ivo brige za integritet prouzrokuje postavljanje inicijalnog nivoa sertifikacije na SCL-3. Ipak posle razmatranja svih relevantnih informacija, rukovodstvo odluu je da smanje nivo sertifikacije na SCL-2, s obzirom na srednji nivo brige za spo ljnju izloenost sistema. Primer 2: Federalni IT sistem obrauje, smeta i prenosi (ta jne) informacije znaajne za nacionalnu bezbednost, za aplikaciju vojne obavetajne slube. Agencija odgovorna za sistem odluuje da je nivo brige za tajnost visok, a d a su nivoi brige za integritet i raspoloivost srednji. Agencija takoe odluuje da je nivo brige za spoljnu izloenost sistema nizak s obzirom na injenicu da svaki pris tup sistemu ide kroz zatiene komunikacione kanale, to jest, iznajmljene linije, ne ma konekcija u pozadini prema sistemu i broj korisnika je vrlo mali (poveren sam o lanovima personala u delu odgovornom za tu aplikaciju). Unutranja izloenost siste ma je takoe procenjena kao mala s obzirom na injenicu da svi slubenici, koji imaju pristup, imaju i odgovarajue bezbednosne dozvole, formalne potvrde za pristup i p otrebu za saznavanje tajnih podataka. Na osnovu gornjih informacija, za sistem s u identifikovani standardni paket za kontrolu sigurnosti i dodatni paket kontrol a za visoku tajnost, srednji integritet i srednju raspoloivost. Konsultujui Tabelu 3.5, niski nivoi brige za spoljnu i unutranju izloenost sistema proizvode nizak n ivo brige za totalnu izloenost sistema. Visok nivo brige za tajnost proizvodi ini cijalni nivo sertifikacije nivoa SCL-3. Ipak, posle prikupljanja svih relevantni h informacija rukovodstvo odluuje da smanje nivo sertifikacije na SCL-1 s obzirom na nizak nivo brige za totalnu izloenost sistema. 3.3.6 ODNOS IZMEU KONTROLA SIGU RNOSTI I NIVOA SERTIFIKACIJE Vano je razumeti odnos izmeu nivoa sertifikacije i ko ntrola sigurnosti. Nivo sertifikacije i kontrole sigurnosti izabrani za IT siste m, su zasnovane na utvrenim nivoima brige za tajnost, integritet i raspoloivost. N ivo brige za izloenost sistema moe uticati na inicijalni izbor nivoa sertifikacije i kontrola sigurnosti, kao to je to ilustrovano u prethodnom odeljku. Standardni paket kontrola sigurnosti i dodatni paket kontrola, definisan od strane agencij e, obezbeuju minimalne kontrole sigurnosti za IT sisteme u oblasti tajnosti, inte griteta i raspoloivosti za niske, srednje, i visoke nivoe brige. Osnovni koncept je, da kako nivo brige raste, sa najnieg nivoa za tajnost, integritet ili raspoloi vost, uvode se dodatne kontrole sigurnosti po diskrecionoj odluci agencije, a pr oces sertifikacije postaje stroiji i u vezi sa tim i intenzitet procesa sertifika cije se poveava, a shodno tome se dodaju novi resursi za sertifikaaciju sistema u z vie nivoe brige i mnogo robusnije kontrole sigurnosti. 3.4 Verifikacija kontrola sigurnosti 43

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Svaka kontrola sigurnosti je pridruena nekom kritinom elementu po NIST Specijalnoj publikaciji 800-53 i ima sebi pridruene procedure i tehnike verifikacije. Tehnik e verifikacije su odreene odabirom SCL, kao to je to ilustrovano u Tabeli 3.4. Pro cedure verifikacije opisuju odreene aktivnosti, koje izvodi sertifikator i sertif ikacioni tim, da bi prikazale korektnu i efikasnu implementaciju kontrole sigurn osti. Specijalna Publikacija 80053A, Tehnike i procedure verifikacije kontrola s igurnosti u Saveznim sistemima za informacione tehnologije, (planirana za prolee 2003), obezbeuje kompletnu listu standardnih tehnika i procedura verifikacije za kontrolu sigurnosti sadrane u NIST Specijalnoj publikaciji 800-53. Tabela 3.6 ilu struje jednostavan primer procedura i tehnika verifikacije za izabrane kontrole sigurnosti u okviru I&A familije. Specijalni odeljak tabele je rezervisan za pro cedure i tehnike verifikacije primenjive na razvojne sisteme. Tabela 3.6 KONTROLE SIGURNOSTI I PROCEDURE VERIFIKACIJA KLASA: TEHNIKA FAMILIJA: IDENTIFIKACIJA I AUTENTIKACIJA (IA) KRITINI ELEMENT: Lozinke, tokeni ili drugi ur eaju korieni za identifikaciju i autentikaciju korisnika KONTROLA SIGURNOSTI IA-1: Tekua lista autorizovanih korisnika i njihovih pristupa se odrava i odobrava . SCL-1 Razvojni ST&E: Nije primenjiv Operativni ST&E: Razmatranje, politika i procedura korisnike autorizacije SCL-2 Razvojni ST&E: Nije primenjiv Operativni ST&E Ispitivanje liste autorizovanih ko risnika i njihovih pristupa SCL-3 Razvojni ST&E: Nije primenjiv Operativni ST&E Ispitivanje liste kontrole sistems kog pristupa i poreenje sa otampanom listom autorizovanih korisnika Razvojni ST&E: Nije primenjiv Operativni ST&E Ispitivanje datoteke sa lozinkama koristei softve r za nadgledanje u cilju verifikovanja da su lozinke promenjene, odgovarajue u pe riodu od 90 dana Razvojni ST&E: Pregled uputstva za administratore radi problene lozinki dobijenih od proizvoaa IA-2: Lozinke za dotini IT sistem se menjaju na najmanje svakih 90 dana ili ranij e ako je potrebno IA-5: Lozinke od proizvoaa se odmah menjaju. Razvojni ST&E: Nije primenjiv Operativni ST&E Razmatranje, politika i procedura za upravljanje lozinkama Intervjuisanje korisnika radi odreivanja familijarnosti korisnika sa politikom i procedurama promene lozinke Razvojni ST&E: Nije primenj iv Operativni ST&E Razmatranje, politika i procedura Razvojni ST&E: Nije primenjiv Operativni ST&E Posmatranje promene korisnikih lozi nki Razvojni ST&E: Nije primenjiv Operativni ST&E Pokazivanje da su lozinke 44

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema dobijene od proi zvoaa zamenjene pokuajem da se loguje pomou standardnom lozinkom proizvoaa Operativni ST&E Ispitivanje datoteke lozinki korienjem softvera za nadgledanje u cilju verifi kacije da su lozinke dobijene od proizvoaa uklonjene sa sistema za zamenu lozinki dobijenih od proizvoaa Intervjuisanje sistem administratora radi odreivanja njihove familijarnosti sa politikom i procedurama izmene lozinki U veini sluajeva, procedure verifikacije su kumulativne, to jest, procedure koriene u odgovarajuem SCL sadre i procedure iz susednog nieg nivoa. U praksi, sertifikator e koristiti predloene procedure aplikacije iz NIST Specijalne publikacije 800-53A , kao polaznu taku, kako bi se razvile specifine ST&E procedura, koje moda, u odreen im sluajevima, treba razviti za odreenu platformu. Na primer, plan testiranja izve den za procedure verifikacije za kontrolu sigurnosti IA-5 iz primera u Tabli 3.6 e obezbediti specifino uputstvo, korak-po-korak, u pokuaju ukljuivanja u Windows 20 00 ili Unix sisteme. Ova dodatna specifinost u ST&E procedurama, doprinosi veoj ko nzistentnosti i ponovljivosti testiranja od sertifikatora do sertifikatora. Kao t o je objanjeno u NIST Specijalnoj publikaciji 800-18, aktivnosti verifikacije tre ba da budu nezavisne od odgovornog rukovodioca za glavne aplikacije ili sistem o pte podrke. Nezavisne verifikacije mogu biti unutranje ili spoljne ali bi trebalo d a se izvode od strane pojedinaca ili organizacija nezavisnih od personala i ekst ernih faktora, koji mogu uticati na njihovu nezavisnost, ili njihovu pretpostavl jenu nezavisnost (na primer, oni projektovani sistem pod nazorom) 45

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Glava 4 PROCES SERTIFIKACIJE I AKREDITACIJE FAZE I AKTIVNOSTI Sigurnost sigurnosti je stepen poverenja, koji neko ima, da e u pravljake, tehnike i operativne kontrole sigurnosti raditi kao to je zamiljenoda bi se zatiili IT sistem i informacije koje on obrauje, memorie ili prenosi... Proces C &A definisan u ovoj publikaciji, stastoji se od etri razliite faze: pred-sertifika cija, sertifikacija, akreditacija, i post-akreditacija. Svaka od ovih faza se od nosi na akreditaciju ma kog sistema (i na operativne postojee sisteme, i na nove razvojne sistem) bez obzira na fazu ivotnog ciklusa u kojoj se sistem nalazi. Sli ka 4.1 ilustruje 4 faze C&A procesa i pojedinane zadatke dodeljene svakoj od faza , koje su detaljnije opisane u sledeim sekcijama. Slika 4.1 Faze i aktivnosti procesa sertifikacije i akreditacije 46

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 4.1 Faza pred-sertifikacije Svrha faze pred-sertifikacije je priprema za aktivnosti verifikacije, koje e se d esiti u fazi sertifikacije. Faza predsertifikacije sadri 6 zadataka: Identifikaci ja sistema; Inicijalizacija i odreivanje okvira; Validacija plana sigurnosti; Val idacija poetne procene rizika; Validacija i identifikacija kontrola sigurnosti; i Konani dogovar (pregovaranje) Znaajan deo informacija potrebnih da bi se kompleti rali zadaci i podzadaci pred-sertifikacije se moe dobiti iz tekuih planova sigurno sti agencije, procene rizika ili druge relevantne dokumentacije. Ako agencija jo uvek nije kompletirala planove sigurnosti i procene rizika, preporuuje se da se o ve aktivnosti kompletiraju pre prelaska na proces C&A. NIST Specijalna publikaci ja 800-18 i 800-30 pruaju uputstva agencijama o pripremanju planova sigurnosti i pristupanju proceni rizika. Nakon kompletiranja faze pred-sertifikacije proces C &A se nastavlja fazom sertifikacije. Sledee sekcije sadre opis svih zadataka i odg ovarajuih podzadataka predsertifikacije. ZADATAK 1: IDENTIFIKACIJA SISTEMA Cilj o vog zadatka je da se utvrdi da svaki plan sigurnosti sadri osnovne informacije o indetifikaciji sistema. Informacije o indetifikaciji sistema sadre takve stavke, kao to su ime sistema, odgovorna organizacija, informacija o kontaktu, odgovorni pojedinci, granice sistema i njegov status. IME / NAZIV SISTEMA PODZADATAK 1.1: Utvrivanje da li plan sigurnosti sadri ime sistema i dodeljivanje jedinstvenog ide ntifikatora sistema. [NIST Specijalna publikacija 800-18] ODGOVORNA ORGANIZACIJA PODZADATAK 1.2: Utvrivanje da li plan sigurnosti sadri ime i lokaciju odgovorne agencije za sistem , kao i organizacije gde se nalaze krajnji korisnici sistema. [NIST Specijalna p ublikacija 800-18] INFORMACIJA O KONTAKTU PODZADATAK 1.3: Utvrivanje da li plan sigurnosti sadri ime, naziv i informaciju o kontaktu (na pri mer, adresa, broj telefona, broj faksa, elektronska 47

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema pota) efa programa, vlasnika sistema, ili lica (licima) koji poseduju odgovarajue z nanje o tom sistemu. [NIST Specijalna publikacija 800-18] DODELJIVANJE ODGOVORNO STI ZA ZATITU PODZADATAK 1.4: Utvrivanje da li plan sigurnosti sadri ime, naziv, adresu i telefonski broj (jedno g ili vie) lica odgovornih za zatitu tog sistema. [NIST Specijalna publikacija 800 -18] GRANICA SISTEMA PODZADATAK 1.5: Utvruje se da li plan sigurnosti opisuje granice sistema za potrebe akreditacije. oblasti odgovornosti za komponente sistema. Razni autoriteti imaju odgovornost za razliite delove sistema, kao to su tekue komponente komunikacija (npr, komunikac ione linije, svievi, ruteri) host-raunari, deljeni ureaji na mrei (npr. printeri, se rveri) i radne stanice i terminali krajnjeg korisnika. Tokom sertifikacije sigur nost ovako kompleksnih sistema, granica i odgovornost za zatitu bilo kog dela, mo ra biti jasno definisana i dokumentovan u planu sigurnosti, kako bi se obezbedil pokrivenost celog sistem. Opis sadri dijagrame ili tekst, koji jasno naglaava koj e komponente treba da budu procenjivane kao deo procesa sertifikacije. Sve sadran e komponente su opisane u opisu sistema, elementi izvan opsega akreditacije su u kljueni u sekciju eksternih interface-a. Dobro pravilo koje treba koristiti za od reivanje granica akreditacije je, da DAA obino ima budet i operativnu kontrolu nad sistemom, koji treba da bude sertifikovana i akreditovana. [NIST Specijalna publ ikacija 800-18, 800-37, sekcija 2.5] SAVET - NAPOMENA: Posto broj i sloenost IT sistema raste, takoe raste i konfuzija oko STATUS SISTEMA PODZADATAK 1.6: Provera da li plan sigurnosti opisuje u kojoj se fazi ivotnog ciklusa taj sistem nalazi, (npr, inicijalna faza, faza razvoja/ prikupljanja, faza implementacije, faza operacije i odravanja, faza gaenja sistema) i navodi listu postojee dokumentac ije, razvoj i plan implementacije, kontrlne take i trokove. [NIST Specijalna publi kacija 800-18] 48

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema ZADATAK 2: INICIJALIYACIJA I ODREIVANJE OBIMA POSLA Cilj ovog zadatka da se inici ra proces C&A i odredi obim poslova u vezi sertifikacije. Tipino, C&A proces se i nicira kroz seriju sastanaka sa kljunim uesnicima DAA, rukovodilac programa, vlasn ik sistema, sertifikator, i lice zadueno za bezbednost sistema i bilo koji drugi pojedinci u agenciji koji imaju interes za sertifikovanje i akreditovanje sistem a. Ove inicijalne serije sastanaka su vane za uspostavljanje potrebne komunikacij e izmeu svih uesnika u C&A procesu. Uesnici dele poetna razmiljanja o razliitim aspekt ima C&A procesa da bi ukljuili 1) nivo brige za tajnost, integritet i raspoloivost (na primer, kritinost / osetljivost sistema), 2) nivo brige i za spoljnu i za un utranju izloenost sistema, i 3) nivo sertifikacije i sigurnosti. Po zavretku ovog z adataka je postignuta opta saglasnost o ovim kljunim stvarima. KRITINOST / OSETLJIV OST SISTEMA PODZADATAK 2.1: Utvrivanje da li plan sigurnosti precizno opisuje kritinost / osetljivost dotinog I T sistema vezano za odgovornost misije agencije. SAVET - NAPOMENA: Kritinost / osetljivost sistema je mera vanosti i prirode informacija koje se obrauju, smetaju ili prenose ovim IT sistemom u odnosu na misiju agencije i svakodnevnih operacija. Kritinost i osetljivost nekog IT si stema i njegovih informacija moe se prikazati analizirajui ta je vlasnik sistema / podataka ili ef programa definisao kao zahteve sistema za tajnost, integritet i r aspoloivost. Tajnost sistema obezbeuje sigurnost da su informacije u nekom IT sist emu zatiene od pristupa neautorizovanih lica, procesa ili ureaja. Integritet sistem a obezbeuje sigurnost da su informacije u nekom IT sistemu zatiene od neautorizovan e, nepredviene i nenamerne izmene ili unitenja. Integritet sistema se takoe odnosi na kvalitet IT sistema u odnosu na logiku korektnost i pouzdanost operativnog sis tema; logiku kompletnost hardvera i softvera kojima se implementiraju mehanizmi s igurnosti i konzistentnost strukture podataka i pojavljivanje memorisanih podata ka. Raspoloivost sistema obezbeuje sigurnost da su informacije i resursi IT sistem a pristupani autorizovanim korisnicima i odgovarajuim sistemskim procesima u pravo m trenutku i da su zatiene od odbijanja servisa. Sprovodei ovu analizu, moe se potvr diti vrednost sistema. Ova vrednost je jedna od osnovnih faktora u upravljanju r izicima. [NIST Specijalna publikacija 800-18, 800-30, 800-37 sekcija 3.1.1] IZLOE NOST SISTEMA 49

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema PODZADATAK 2.2: Utvrivanje da li plan sigurnosti precizno opisuje spoljnu i unutranju izloenost dot inog IT sistema. SAVET - NAPOMENA: Izloenost sistema je mera potencijalnog rizika pretnji, kako unutranjih tako i spoljanjih, za neki IT sistem. Spoljna izloenost si stema se odnosi na 1) metod kojim korisnici pristupaju sistemu, 2) postojanje po vezanosti u pozadini, i ako ta povezanost postoji, prema kojim sitemima je povez an, 3) broj korisnika koji pristupaju sistemu. Unutranja izloenost sistema se odno si na tipove pojedinaca koji imaju autorizaciju za pristup sistemu i informacija ma koje sistem obrauje, memorie ili prenosi. Ona sadri takve stavke, kao to su pojed inani nivoi dozvola, dozvole pristupa, dozvola za znanje osetljivih informacija. Interna izloenost sistema se razmatra za IT sisteme koji obrauju, memoriu ili preno se (tajne) informacije od znaaja za nacionalnu bezbednost ili (bez zvaninog stepen a poverljivosti) ali osetljive na nivo brige za tajnost. Spoljna izloenost sistem a se takoe razmatra kod IT sistema sa visokim nivoom brige za integritet. [NIST S pecijalna publikacija 800-37 sekcije 3.1.2, 3.1.3] SERTIFIKACIJA NIVOA SIGURNOST I PODZADATAK 2.3: Izabrati nivo sertifikacije sigurnosti (na primer, SCL-1, SCL-2 ili SCL-3) za IT sistem; ili za velike i kompleskne sisteme, izabrati nivo sertifikacije sigurno sti za sve komponente koje su na nivou podsistema u okviru opsega akreditacije. SAVET - NAPOMENA: Postoje tri koraka u izboru SCL: 1) Okarakterisati IT sistem, 2) izabrati inicijalni SCL, 3) podesiti inicijalni SCL s obzirom na nivoe brige za spoljnju izloenost sistema i ukoliko je to odgovarajue za unutranju izloenost sis tema. [NIST Specijalna publikacija 800-37 sekcije 3.1, 3.3.5] ZADATAK 3: POTVRIVANJE PL ANA SIGURNOSTI Cilj ovog zadatka je potvrditi da li plan sigurnosti: 1) sadri pun i taan opis datog IT sistema i njegovog operativnog okruenja, 2) identifikuje zah teve za sigurnost datog sistema, 3) opisuje odgovornosti i oekivano ponaanje pojed inaca koji pristupaju tom sistemu. Opis sistema sadri misiju, funkcije i mogunosti . pregled arhiktetura sistema (hardver, softver, firmvare i pridrueni interface) se daje uporedo sa opisom prostorija gde se sistem nalazi i opisom odgovornih or ganizacija i pojedinaca, koji su nadleni da eksploatiu sistem. Zahtevi za sigurnos t artikuliu tipove i nivoe sigurnosti, potrebne za opremu, podatke, informacije, aplikacije i prostorije kako bi odgovarajui zakoni, direktive, uredbe, standardi, instrukcije i / 50

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema ili politike sigurnosti bili zadovoljeni. Kontrole sigurnosti ukljuuju upravljaki, operativni i tehniki mere sigurnosti upotrebljene da bi se titile informacije u t om IT sistemu. OPTI OPISI I SVRHA PODZADATAK 3.1: Utvrivanje da li plan sigurnosti, u optim crtama, opisuje svrhu, funkciju i mogunos ti datog sistema, kao i informacija koje on obrauje, uva i prenosi. SAVET - NAPOMENA: Opti opis lista sve aplikacije koje ovaj sistem podrava kao i funkcionalni opis i svrhu svake podrane aplikacije. Funkcionalni dij agrami i tokovi procesa, od ulaza u sistem do izlaza iz sistema, su ukljueni u op is sistema. Ukoliko postoji koncept operacija, na njega se poziva ili se ukljuuje , kao prilog, planu sigurnsoti sistema. [NIST Specijalna publikacija 800-18] PODZADATAK 3.2: Potvrda da li plan sigurnosti i spoljanje, identifikacija e primenljivo, identifikacija [NIST Specijalna publikacija PODZADATAK 3.3: Utvrivanje da li plan sigurnosti opisuje prava pristupa korisnika ili dozvole pri stupa onformacijama koje sistem obrauje, uva ili prenosi, ukljuujui sva privilegovan a radna mesta ili privilegovane korisnike sistema. Korisnici sistema mogu biti s talni dravni slubenici i slubenici pod ugovorom. Ako su informacije, koje se obrauju , uvaju ili prenose, vlasnitvo neke komercijalne organizacije formiraju se dovoljn o dobre kontrole u okviru sistema da spree slubenike pod ugovorom da ostvare namer avan ili sluajan pristup tim informacijama. [NIST Specijalna publikacija 800-18] OKRUENJE SISTEMA PODZADATAK 3.4: Utvrivanje da li plan sigurnosti opisuje sistemski hardver i njegove funkcije. SAVET - NAPOMENA: Opis sistemskog hardvera ukljuuje listu opreme, crtea i dijagrame koji ine opis jasnim. Ako potrebe razvoja ukljuuju promen e postojeeg hardvera, treba izvriti identifikaciju specifinih hardverskih komponent i koje se menjaju. Identifikovati 51 sadri sve korisnike organizacije, kako unutranje tako korisnika sistema koji nisu dravljani zemlje, i ako j tipa informacija i obrade koje su na raspolaganju. 800-18]

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema izvor snabdevanja hardverom sistema, bilo da je COTS (Commercial off-the-shelf) ili GOTS (Government off-the-shelf), i obezbediti informacije koje se odnose na procenu i potvrdu, ukoliko je mogue. Program procene proizvoda ukljuuje NIST Progr ami validacije kriptograpskih modula (FIPS 140-2), Udruenje osiguranja nacionalni h informacija (NIAP), Opti program kriterijuma i validacije (ISO/IEC 15408), ili druge programe procene potvrene od strane vlade.. [NIST Specijalna publikacija 80 0-18] PODZADATAK 3.5: Utvrivanje da li plan sigurnosti opisuje sistemski firmver i njegove funkcije. SAVET - NAPOMENA: Opis sistemskog firmvera ukljuuje, na primer, programabilne PROM memorije, PROM (EPROM) ureaje ili RAM ureaje. Treba identifikov ati izvore snabdevanja firmverom, bilo da je to COTS ili GOTS i obezbediti infor macije koje se odnose na evaluaciju i validaciju, ukoliko je to mogue. Program pr ocene proizvoda ukljuuje NIST Programi validacije kriptograpskih modula (FIPS 140 -2), Udruenje osiguranja nacionalnih informacija (NIAP), Opti program kriterijuma i validacije (ISO/IEC 15408), ili druge programe procene potvrene od strane vlade .. [NIST Specijalna publikacija 800-18] PODZADATAK 3.6: Utvrivanje da li plan sigurnosti opisuje sistemski softver (operativni sistem, mi ddleware, sistem upravljanja bazama podataka i softver za zatitu) i softverske ap likacije podrane od strane sistema i kako e oni biti korieni. SAVET - NAPOMENA: Opis softvera sadri softver dobijem od proizvoaa i sav programski generisan aplikativni softver. Identifikovati izvor sna bdevanja sistemskim i aplikativnim softverom koji je ili COTS ili GOTS i obezbed iti informacije koje se odnose na evaluaciju i validaciju, ukoliko je to mogue. P rogram procene proizvoda ukljuuje NIST Programi validacije kriptograpskih modula (FIPS 140-2), Udruenje osiguranja nacionalnih informacija (NIAP), Opti program kri terijuma i validacije (ISO/IEC 15408), ili druge programe procene potvrene od str ane vlade.. [NIST Specijalna publikacija 800-18] 52

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema PODZADATAK 3.7: Utvrivanje da li plan sigurnosti opisuje spoljne interfase prema sistemu ukljuujui i svrhu svakog spoljnog interfase i odnos tog interfasa prema sistemu. [NIST Spe cijalna publikacija 800-18] PODZADATAK 3.8: Utvrivanje da li plan sigurnosti opisuje spoljne interfase prema sistemu, tokove podataka ukljuujui tipove podataka opte metode prenosa podataka i medije za prenos ili interfase prema drugim sistemima. SAVET NAPOMENA: Opis ukljuuje dijagram ili tekst kojim se objanjava tok kritinih in formacija od jedne komponente ka drugoj. [NIST Specijalna publikacija 800-18] PODZADATAK 3.9: Utvrivanje da li plan sigurnosti opisuje fiziku okolinu u kojoj sistem radi, ukljuu jui i planove prostorija, smetaj opreme, emu kanalizacionih i elektrinih instalacija , telefonskih instalacija, klima ureaja, sistem protiv poarne sigurnosti, ventilat ore, alarme sisteme, uvare, itd. [NIST Specijalna publikacija 800-18] PODZADATAK 3.10: Utvrivanje da li plan sigurnosti sadri broj i profil potrebnog personala koji e rad iti na odravanju IT sistem. [NIST Specijalna publikacija 800-18] MEUSOBNA POVEZANOST SISTEMA I RAZMENA INFORMACIJA PODZADATAK 3.11: Utvrivanje da li plan sigurnosti sadri meusobno povezane sisteme i jedinstvene iden tifikatore sistema (ako je to potrebno) [NIST Specijalna publikacija 800-18] PODZADATAK 3.12: Utvrivanje da li plan sigurnosti opisuje vane osobine komunikacionih konfiguracija , ukljuujui dijagram,o komunikacionim linkovima i tehnikama ifriranja, koji povezuj e komponente sistema, pridruenu razmenu podataka i mree. [NIST Specijalna publikac ija 800-18] PODZADATAK 3.13: Utvrivanje da li plan sigurnosti opisuje pravila za povezivanje mree, kada je dotin i sistem povezan sa drugim spoljnim sistemima. 53

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema SAVET - NAPOMENA Posle indentifikacije opsega akreditacije, sve veze prema sistemu van tog opsega je potrebno je identifikovati. Svrha spoljnih veza i odnosa izmeu povezanih sistema se mora dokumentovati. Agencije mogu imati dodatne zahteve u vezi sigurnosti za spoljne sisteme, koji se povezuju na dati s istem. Ti dodatni zahtevi, kao i zahtevi drugih sistema koji mogu biti povezani na dati sistem, dodaju se u plan sigurnosti sistema i vri se njihova procena toko m procedure sertifikacije sistema. C&A dokumentacija se dobija iz spoljnih siste ma, da bi se odredili rizici povezivanja sa tim sistemima. Pisana autorizacija ( na primer MOU/MOA i Interconnection security agreements) Moe biti dobijene pre pove zivanja sa drugim sistemima i / ili razmene osetljivih informacija. [NIST Specij alna publikacija 800-18, 800-47] PODZADATAK 3.14: Utvrivanje da li plan sigurnosti opisuje, ako je primenjivo, znaajne osobine web p rotokola i okruenje raunarske kolaboracije, u ta mora biti ukljueno: 1) kontrola sig urnosti na web serverima i klijentima, 2) koriene mobilnog koda i / ili izvrnog sad raja, 3) bilo koji procesi ili aplikacije raunarske kolaboracije, i bilo koja dist ribuirana obrada upotrebljena od strane sistema. [NIST Specijalna publikacija 80 0-18] PODZADATAK 3.15: Utvrivanje da li plan sigurnosti opisuje, ako je primenjivo, bilo koji beini (RF il i IR) ureaj, koji se koristi u sistemu. [NIST Specijalna publikacija 800-18] PODZADATAK 3.16: Utvrivanje da li plan sigurnosti opisuje, ako je primenjivo, korienje infrastruktur e javnih kljueva (PKI) i identifikovanje svih ovlaenih sertifikatora i pravila za u potrebu sertifikata. [NIST Specijalna publikacija 800-18] ODGOVARAJUI ZAKONI, REGULATIVA, STANDARDI I POLITIKA OD UTICAJA NA DATI SISTEM PODZADATAK 3.17: Utvrivanje da li plan sigurnosti sadri bilo koje zakone koji se primenjuju, regula tivu, instrukcije, direktive, standarde ili politikestrategije, koji postavljaju specifine zahteve sigurnosti u odnosu na tajnost, integritet ili raspoloivost inf ormacija u okviru datog sistema, kao i odgovornost pojedinaca koji koriste siste m. 54

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema SAVET - NAPOMENA: Direktive nacionalnog nivoa, OMB cirkularna pisma (A-123, A-130), opte direktive agencijama, direktive agencija na nivou komp onenti, politike i zahtevi, ne bi trebalo da budu prikazani, jerse oni staraju o sigurnosti svih sistema. Treba prikazati samo one koji su specifini za dati IT s istem. [NIST Specijalna publikacija 800-18] ZADATAK 4: INICIJALNA PROCENA RIZIKA Cilj ovog zadatka je da potvrdi da inicijalna procena rizika sadri identifikacij u pretnji i ranjivost IT sistema. Inicijalna procena rizika se ne izvodi u sklad u sa formalnom analizom slabosti, ali obezbeuje ulaz za mnogo stroiju analizu slab osti, koja e se izvoditi kasnije tokom faze sertifikacije. IDENTIFIKACIJA PRETNJI PODZADATAK 4.1: Utvrivanje da li je inicijalna procena rizika identifikovala i sadri izvore potenc ijalnih pretnji, koji mogu koristiti ranjivost sistema i imati efekta na tajnost , integritet i raspoloivost datog sistema. SAVET - NAPOMENA: U procenjivanju pretnje, vrlo je vano uzeti u obzir sve potenci jalne izvore pretnje, koji mogu nakoditi sistemu i njegovom okruenju. Pretnje mogu biti prirodne (poplave, zemljotresi, tornado, klianje zemljita, lavina, munje i g romovi), pretnje od strane oveka (dogaaji koje omoguavaju ili prouzrokuju ljudi), i li pretnje iz okruenja (dugotrajni nestanci struje, zagaenost vazduha, hemikalije, curenje tenosti). Treba naglasiti, da se ne moraju uzeti u obzir sve mogue pretnj e iz okruenja, ve samo one od vanosti za siguran rad sistema. [NIST Specijalna publikacija 800-30] IDENTIFIKACIJA RANJIVOSTI SISTEMA PODZADATAK 4.2: Utvrivanje da li inicijalna procena rizika identifikuje i sadri slabosti sistema, (na primer mane ili slabosti), koje mogu iskoristiti potencijalni izvori pretnji . SAVET NAPOMENA: Identifikaciji izvora ranjivosti se moe pristupiti u bilo kojoj fazi ivotnog ciklusa razvoja sistema. Ako sistem jo uvek nije osmiljen , istraivanje ranjivosti bi trebalo da se fokusira na politiku sigurnosti organiz acije, planiranje procedure sigurnosti i definicije zahteva sistema kao i analiz u proizvoda koji se koriste za razvoj sigurnosti. Ako je posmatrani sistem u faz i implementacije, identifikaciju ranjivosti treba proiriti tako da sadri mnogo 55

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema specifinije informacije, kao to su planirane karakteristike sigurnosti opisane u p rojektnoj dokumentaciji sigurnosti i rezultati razvojnog C&A. Ako je sistem oper ativan, proces identifikacije ranjivosti bi trebalo da sadri analizu kontrola sig urnosti sistema (upravljakih, operativnih i tehnikih) koje se koriste da sigurnost i sistem. Tokom inicijalne procene rizika, ranjivost sistema se moe identifikovat i korienjem izvora u vezi ranjivosti opisanih u NIST Specijalnoj publikaciji 800-3 0. U narednoj fazi C&A procesa (faza sertifikacije) koriste se mnogo ire ST&E akt ivnosti za otkrivanje dodatnih ranjivosti sistema. [NIST Specijalna publikacija 800-30] ZADATAK 5: UTVIVANJE I IDENTIFIKACIJA KONTROLA SIGURNOSTI Cilj ovog zadat ka je da se: 1) utvrdi da li plan sigurnosti opisuje kontrole sigurnosti za dati IT sistem, 2) identifikuje bilo koje dodatne kontrole sigurnosti koje ne postoj e u planu sigurnosti. Izbor kontrola sigurnosti se zasniva na inicijalnoj karakt erizaciji sistema iz plana sigurnosti, a ma koja dodatna izabrana ili kreirana k ontrola na osnovu poetne procene rizika. POTVRIVANJE KONTROLA SIGURNOSTI PODZADATAK 5.1: Potvrivanje da plan sigurnosti sadri potrebne kontrole sigurnosti datog IT sistema (npr, upravljake, operativne, i tehnike kontrole) na osnovu karakterizacije siste ma (koja se dobija iz plana sigurnosti), a iskazane su novoom brige (nizak, sred nji ili visok) za tajnost, integritet i raspoloivost; aurirati plan sigurnosti, uk oliko je potrebno. SAVET NAPOMENA: Minimalne kontrole sigurnosti za savezne IT sisteme su date u NIST Specijalnoj publikaciji 800-53. Postoji pre definisan sta ndardni paket kontrola sigurnosti i dodatni paket kontrola koje mogu biti kreira ne od strane agencije. Standardni paket sadri osnovni nivo kontrole sigurnosti za tajnost, integritet i raspoloivost. Osnovni skup kontrola sigurnosti bi trebalo primeniti u svim federalnim sistemima. Dodatni paket dozvoljava agencijama da po veaju nivo sigurnosti svojih IT sistema, izborom dodatne kontrole sigurnosti gde je to potrebno. Dodatni paket korespondira sa poveanim nivoima brige, izraenim od strane agencije, u oblastima tajnosti, integriteta, i raspoloivosti. Minimalne ko ntrole sigurnosti mogu biti uveane sa dodatnim kontrolama, ako je to potrebno, a u skladu sa politikom agencije i zahtevima sigurnosti. U cilju sumiranja procesa utvrivanja identifikacije kontrola za dotini sistem daje se sledee: Utvrditi da pl an sigurnosti sadri minimalne kontrole sigurnosti iz standardnog paketa osnovnih kontrola (obavezno za sve sisteme). [NIST Specijalna publikacija 800-30] 56

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Identifikovati dodatne minimalne mere kontrole (srednji / visoki nivoi) ukoliko je odgovarajue, da bi se formirao dodatni paket kontrola baziran na poveanim nivoi ma brige za tajnost, integritet, i / ili raspoloivost. [NIST Specijalna publikaci ja 80030] Kreirati dodatne, specifine za agenciju. ili tehnoloki neophodne kontrol e sigurnosti, [ako potrebne kontrole sigurnosti nisu raspoloive u okviru [NIST Sp ecijalne publikacije 800-53] Podesiti izabrane kontrole u odnosu na unutranju / s poljnju izloenost sistema i odluke vezane za rizik; opisati kontrole i dokumentov ati ih na zahtevu. [NIST Specijalna publikacija 800-18, 800-30, 800-53] LISTA DODATNIH KONTROLA PODZADATAK 5.1: U vezi ranije identifikovane kritinosti/osetljivosti, treba napraviti listu ident ifikacije kontrola, za sve kontrole sigurnosti, koje treba dodati u plan sigurno sti i implementirati Ove, dodatne kontrole bi na konanom dogovoru trebalo prodisk utovati . (zadatak 6). SAVET NAPOMENA: C&A proces definie aktivnosti, procene, neophodne za potvrdu da su kontrole sigurnosti korektno implementirane i da su e fikasne. Identifikacija i korektna i efikasna implementacija kontrola sigurnosti je neophodan uslov da se obezbedi saglasnost sa zahtevima za sigurnost sistema. [NIST Specijalna publikacija 800-37] ZADATAK 6: DOGOVOR Cilj ovog zadatka je da se potvrde informacije dobijene tokom faze predsertifikacije i da se pristupi k onanom dogovoru svih nadlenih uesnika u C&A procesu, pre prelaska na stvarnu fazu s ertifikacije. Dogovor prua mogunost DAA, efu programera, vlasniku sistema, vlasniku informacija, licu zaduenom za zatitu, i sertifikatoru da jo jednom analiziraju uti caje i domet planiranih C&A aktivnosti i da postignu konani dogovor o nivoima bri ga za tajnost, integritet i raspoloivost, nivoom brige za sistemsku izloenost, niv o sertifikacije, kontrole sigurnosti, preostali rizik i kako e preostale C&A snag e biti upotrebljene. PODZADATAK 6.1: Pristupanje finalnom dogovoru sa svim uesnicima C&A procesa vodi ka postizanja sa glasnosti u vezi obima, skupa aktivnosti i vremenskog plana. 57

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema [NIST Specijalna publikacija 800-37] 4.2 Faza sertifikacije Svrha faze sertifikacije je da pokae, kroz nezavisnu procenu koristei izabrane teh nike i procedure verifikacije, da su kontrole sigurnosti za dati IT sistem imple mentirane korektno i da su efikasne u svojoj primeni. Korektna i efikasna implem entacija kontrola sigurnosti je neophodan uslov da bi se pokazala saglasnost sa zahtevima sigurnosti sistema. Rezultati faze sertifikacije su dokumentovani u ra zvojnim i / ili operativnim ST&E izvetajima, koji su ukljueni u zavrni paket sertif ikacije zajedno sa planom sigurnosti i konanim izvetajem o proceni rizika. Faza se rtifikacije se sastoje od 2 zadatka: Doterivanje procedure verifikacije Testiran je i procena sigurnoste (ST&E) Zadaci faze sertifikacije su pogodni za nove sist eme, za manje i vee dogradnje sistema i postojae sisteme. NIST Specijalna publikac ija 800-53a (Predviena za Prolee 2003) pravi razliku izmeu razvojnih i operativnih ST&E aktivnosti u odreenim procedurama verifikacije napravljenim za kontrole sigu rnosti. Svaka procedura verifikacije moe imati razvojnu ST&E komponentu i operati vnu ST&E komponentu. Tipino, razlika izmeu razvojnih i operativnih procedura opera cija je u koliini raspoloivih informacija na odreenom stupnju ivotnog ciklusa razvoj a sistema. Za razvojni ST&E postoje brojne predpostavke napravljene u vezi okruen ja, u kom e sistem iveti, koje ne mogu biti potpuno verifikovanje dok se sistem ne pusti u rad. Nakon kompletiranja faze sertifikacije, C&A proces se nastavlja fa zom akreditacije. Sledee sekcije sadre opis svih zadataka sertifikacije i odgovara juih pod zadataka. ZADATAK 7: DOTERIVANJE PROCEDURE VERIFIKACIJE Cilj ovog zadatk a je da se razviju, gde je to potrebno, odgovarajua doterivanja procedura verifik acije pridruenih kontrolama sigurnosti, u standardnom i dodatnom paketu, da bi se , za sistem, kreirali specifini tehniki i ne tehniki testovi. NIST Specijalna publi kacija 800-53a (Predviena za prolee 2003) obezbeuje preporuene tehnike verifikacije i generalizovane procedure verifikacije za sve kontrole sigurnosti. Ove tehnike i procedure su vodi za sertifikatore, koje treba strogo primeniti u procesu verif ikacije (ciljano na odabrane SCL) i procesu dokazivanja da su kontrole sigurnost i implementirane korektno i efikasne pri korienju. Meutim, doterivanje procedure ve rifikacije, znai krojenje procedure verifikacije za potrebe specifinog sistema i o kruenja u kome taj sistem radi (ili u sluaju novih sistema, gde se namerava da se sistem pusti u rad). Doterivanja procedura verifikacije se radi samo u sluaju da originalne procedure verifikacije kontrola sigurnosti (date u Specijalnon publik aciji 800-53) ne pruaju dovoljno informacija sertifikatoru, da bi na adekvatan nai n pokazao da su kontrole sigurnosti sistema korektno implementirane i efikasne. PODZADATAK 7.1: Razvoj, ako je potrebno, doterivanja procedura verifikacije pridruenih osnovnim k ontrolama sigurnosti u standardnom paketu i dodatnim 58

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema kontrolama u dodatnom paketu definisanom od strane agencije (ako je primenjivo). SAVET NAPOMENA: Doterivanje procedura verifikacije moe biti neophodno za razvoj specifinih ST&E aktivnosti za odreene sisteme, platforme i / i li radna okruenja. Na primer, provera implementacije mehanizma identifikacije i a utentifikacije korienjem lozinke, moe zahtevati specifine informacije u vezi sistema koji se sertifikuje i akredituje, (na primer, Windows vs Unix sistemi). Tehnike verifikacije, procedure verifikacije i dorade procedura obezbeuju osnovne inform acije sertifikatoru da efikasno sprovede odgovarajue ST&E aktivnosti, na odabrano m SCL nivou. [NIST Specijalna publikacija 800-37] ZADATAK 8: PROCENA SIGURNOSTI (ST&E) Cilj ovog zadatka je da 1) korienjem odgovarajuih tehnika verifikacije, proc edura verifikacije i ako je potrebno doterivanjem procedura, pokae da su upravljak e, operativne, i tehnike kontrole sigurnosti za dati IT sistem primenjene korektn o i da su efikasne u svojoj primeni, i 2) na osnovu rezultata ST&E, pripremi kon ani S&T izvetaj ili izvetaj aktivnosti izvrenih tokom faze sertifikacije. SCL-1 PODZADATAK 8.1a: Pokazati, kroz nezavisnu procenu, koristei tehnike verifikacije SCL-1 i procedure verifikacije (sa doradom procedura ako je potrebno), da su osnovne kontrole sig urnosti iz standardnog paketa i dodatno kontrole definisane od strane agencije u dodatnom paketu (ako je primenjivo) implemetirane korektno i da su efikasne u s vojoj primeni. Pokazati, kroz nezavisnu procenu koristei tehnike verifikacije SCL -2 i procedure verifikacije (sa doradom procedura ako je potrebno), da su osnovn e kontrole sigurnosti iz standardnog paketa i dodatno kontrole definisane od str ane agencije u dodatnom paketu implemetirane korektno i da su efikasne u svojoj primeni. Pokazati, kroz nezavisnu procenu koristei tehnike verifikacije SCL-3 i p rocedure verifikacije (sa doradom procedura ako je potrebno), da su osnovne kont role sigurnosti iz standardnog paketa i dodatno kontrole definisane od strane ag encije u dodatnom paketu implemetirane korektno i da su efikasne u svojoj primen i. SAVET NAPOMENA : Odreene SCL-1, SCL-2 i SCL-3 tehnike SCL-2 PODZADATAK 8.1b: SCL-3 PODZADATAK 8.1c: verifikacije (npr, razmatranje, posmatranje, intervju, prouavanje, 59

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema prikazivanje, vebanje, testiranje, analiziranje, itd) i procedure verifikacije za kontrole sigurnosti koje se odnose na upravljanje rizikom, razvoj i akviziciju sistema, upravljanje konfigurisanjem, povezivanje sistema, personalnu zatiti, zati te medija, fiziku zatiti i zatitu okoline, planiranje nepredvienih situacija, mogunos t odgovora na incidente, odravanje sistemskog softvera i hardvera, integriteu pod ataka sistema, svesnost o zatiti, obukui i dokumentaciju, identifikacij, i autent ifikaciju, logiki pristup, praenje, i vrste komunikacija date su u NIST Specijalno j publikaciji 800-53. Agencije koje imaju uveane minimialne kontrole sigurnosti u standardnim i / ili dodatnim paketima, treba da koriste tehnike verifikacije i procedure verifikacije pripremljene u zadatku 5, da bi prikazale da su dodatne k ontrole ugraene korektno i da su efikasne. [NIST Specijalna publikacija 800-37, 8 00-53] PODZADATAK 8.2: Pripremanje konanog ST&E izvetaja (jednog ili vie) SAVET NAPOMENA : Agencija definie format konanog ST&E izvetaja. Bez obzira na to, izvetaj mora jasno da pokae rezultate primene procedura verifikacije i dorade procedura za kontrole sigurnosti za taj IT sistem. U doda tku odredaba, gde stoji koje su kontrole implementirane korektno i da su efikasn e u svojoj primeni, ST&E izvetaj identifikuje koje kontrole sigurnosti su samo de limino primenjene ili primenjene nekorektno ili nisu efikasne. Konani ST&E izvetaj je kljuni ulaz za konanu procenu rizika. [NIST Specijalna publikacija 800-37, 80053] 4.3 Faza akreditacije Svrha faze akreditacije je da dovri konanu procenu rizika za dati IT sistem, aurira plan sigurnosti, pripremi rezultate sertifikacije i izda odluku o akreditaciji. Konana procena rizika uzima se zasniva na ST&E rezultatima faze sertifikacije, k ako bi se odredio preostali rizika za sistem, posle nepristrasne procene korektn osti i efikasnosti kontrola sigurnosti. Zakljuci postupka sertifikacije se sakupl jaju i u zavrnom paketu sertifikacije se nalaze sve relevantne informacije, ukljuu jui i auriran plan sigurnosti, ST&E izvetaji, konani izvetaj o proceni rizika i odluk u sertifikatora. Sertifikacioni paket sadri osnovnu evidenciju koju DAA koristi d a donese odluku, zasnovanu na informacijama i proceni rizika, punoj akredituji, deliminoj akredituji ili da ne akredituje IT sistem za rad. Faza akreditacije sad ri 4 zadatka: Konana procene rizike; Auriranje plana sigurnosti; 60

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Zakljuci sertifikacije; i Odluka o akreditaciji Nakon zavretka faze akreditacije, C&A proces ulazi u konanu fazu, fazu post akredi tacije. Sledee sekcije sadre opis svih zadataka akreditacije i pridruenih podzadata ka. ZADATAK 9: KONANA PROCENA RIZIKA Cilj ovog zadatka je da odredi preostali riz ik za dati IT sistem na osnovu rezultata ST&E aktivnosti, koje su se odvijale to kom faze sertifikacije. ST&E aktivnosti primenom serije tehnika verifikacije i p rocedura verifikacije, pokazuju koje su kontrole sigurnosti sistema korektno ugr aene i efikasne u svojoj primeni, a koje kontrole to nisu. Delimina implementacija i / ili nepostojanje kontrola sigurnosti se takoe identifikuje tokom faze sertif ikacije. Preostali rizik, koji se dokumentuje u konanom izvetaju procene rizika, o pisuje rizik koji za sistem i dalje postoji posle ublaavanja rizika (npr, kontrol e sigurnosti su ugraene, procenjene, i korekcije su inicirane). DAA odreuje stepen prihvatljivog preostalog rizika (sa ulazima od efa programera i vlasnika sistema / podatak) u saglasnosti sa zahtevima misija agencije. PODZADATAK 9.1: Odrediti preostali rizik za dotini IT sistem. [NIST Specijalna publikacija 800-30 , 800-37, 800-53] ZADATAK 10: AURIRANJE PLANA SIGURNOSTI Cilj ovog zadatka je da aurira plan sigurno sti, na osnovu rezultata ST&E aktivnosti i konane procene rizika. PODZADATAK 10.1: Aurirati plan sigurnosti. [NIST Specijalna publikacija 800-18, 800-37] ZADATAK 11: REZULTATI SERTIFIKACIJE Cilj ovog zadatka je priprema konanih rezulta ta sertifikacije i da se kompletira konani paket sertifikacije za DAA. Paket sert ifikacije, pripremljen za sertifikatora, sadri aurirani plan sigurnosti, razvojne ili operativne ST&E izvetaje, konani izvetaj procene rizika i sertifikacionu odluku . Rezultati sertifikacije predstavljaju kolektivni sud sertifikatora i sertifika cionog tima u proceni tehnike korektnosti i operativne efikasnosti kontrola sigur nosti, koji se smatraju obaveznim za dotini IT sistem. Ta nezavisna tehnika i ne t ehnika procena ima za cilj da prui najkompletnije mogue informacijame DAA, vezano z a stanje upravljakih, operativnih, i tehnikih kontrola datog IT sistema. Rezultati sertifikacije sadre i preporuku DAA o moguem ublaavanju preostalog rizika, koji je identifikovan kao rezultat ST&E. 61

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema PODZADATAK 11.1: Pripremiti konane rezultate sertifikacije i kompletirati konani paket sertifikacij e. SAVET NAPOMENA: Rezultati sertifikacije, kroz odluku o sertifikaciji i povratnu dokumentaciju, obezbeuju DAA-u vane informacije neophodne da donese odluku na osno vu informacija i procene rizika u pogledu rada datog IT sistema. Faza sertifikac ije je usko usredsreena na sprovoenje odgovarajuih ST&E aktivnosti sa izriitom namen om da pomou kroz odabranih tehnika verifikacije i procedure verifikacije prikae, d a su potrebne kontrole sigurnosti implementirane korektno i da su efikasne u svo joj primeni. Odluka o sertifikaciji se odraava i na stanje kontrola sigurnosti ve zanih za rezultate ST&E aktivnosti, koje je sproveo sertifikator i sertifikacion i tim. [NIST Specijalna publikacija 800-18, 800-37] ZADATAK 12: ODLUKA AKREDITACIJE Cil j ovog zadatka je da DAA izvri uvid u evidenciju unetu u sertifikacioni paket, (n pr. plan sigurnosti, ST&E izvetaj(i) i konani izvetaj o proceni rizika, sertifikaci ona odredba), i da izda konanu akreditacionu odluku za dati IT sistem. Ova eviden cija predstavlja najbolju nezavisnu procenu korektnosti i efikasnosti upravljakih , operativnih, i tehnikih kontrola sigurnosti upotrebljenih da bi se zatitio IT si stem svom radnom okruenju. Odluka akreditacije uzima u obzir stanje kontrola sigu rnosti za dati sistem kao i za zahteve misije agencije koja donosi odluku. Nivo preostalog rizika, posle primene potrebnih kontrola sigurnosti, procene korektno sti i efikasnosti tih kontrola, umanjivanja uticaja svih neprihvatljivih rizika, sistema koji izvrava svoju radnu misiju, mora biti u okviru tolerantnih granica, koje postavlja DAA. PODZADATAK 12.1: Revizija paketa sertifikacije izdanje konane dozvole za akreditaciju. SAVET NAPOMENA: Na osnovu informacija koje su raspoloive u konanom sertifikacionom paketu, (npr. plan sigurnosti, razvojni i/ili operativni ST&E izvetaj, konani izv etaj o proceni rizika, i sertifikaciona odredba) DAA moe napraviti odluku na bazi procene rizika i to da 1) dozvoli akreditaciju sistema, 2) da izda privremenu do zvolu za rad sistema ili 3) da poniti akreditaciju sistema jer postojei rizici nis u na prihvatljivom nivou. Za punu akreditaciju ne postoje nikakve restrikcije. Z a privremenu akreditaciju sistem ne ispunjiva sve zahteve o zatiti definisane u p lanu sigurnosti i ne formira sve potrebne kontrole sigurnosti da bi se u potpuno sti zatitile informacije koje se obrauju, uvaju ili prenose. Kritinost misije zahtev a da sistem bude operativan, i ne postoji nijedna druga varijanta da adekvatno o bavi tu misiju. Privremena akreditacija je privremeno data dozvola, za minimalni period vremena, neophodan da se dostignu zahtevi sigurnosti IT sistema ili se u grade potrebne kontrole sigurnosti navedene u planu sigurnosti. U sluaju odbaciva nja akreditacije, 62

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema sistem ne zadovoljava zahteve za zatitu datu u planu sigurnosti, a kontrole sigur nosti ili ne postoje ili su vrlo neefikasne. Prihvaeni rizik je suvie veliki tako da kritinost misije ne nalae trenutnu operativnu potrebu. Odluka o akreditaciji je dokumentovana u konanom akreditacionom paketu, koji se sastoji od akreditacionog pisma i dokumentacije koja podrava i odnosi se na akreditacionu odluku. U nekim situacijama, moe se ukljuiti vie DAA za jedan IT sistem. Ako je tako, to mora biti dokumentovano u akreditacionom paketu. U veini sluajeva, povoljnije je da se izabe re vodei DAA, koji predstavlja sve ostale DAA tokom C&A procesa. [NIST Specijalna publikacija 800-37] PODZADATAK 12.2: Za privremene akreditacije, treba ugraditi operativne restrikcije i izdati privr emeni akcioni plan akreditacije. SAVET NAPOMENA: Kada sistem mora biti operativan, s obzirom na svoju vanost u odnosu na misiju koju treba da obavi a sa nedostacima u zatiti (npr , kontrole sigurnosti nisu korektno ugraene, ne efikasne su ili nedostaju), uvode se operativna ogranienja rada. Mogu se uvesti protivmere (odreena zatita) ali su o ne obino ograniene na proceduralne i mere fizike zatite. Nije praktino niti ekonomski opravdano, pod normalnim uslovima, dodavati interne tehnike kontrole u kasnijim fazama ivotnog ciklusa sistema. Odabrane karakteristike sistema, koje preuzrokuju glavne probleme ili stvaraju veliki rizik, mogu biti izbaene ili njihova ugradnj a prolongirana. Takoe se moe ograniiti broj korisnika ili korisnikih privilegija. Ud aljeni terminali se mogu fiziki ili logiki iskljuiti, kada se obrauju ili memoriu ose tljive (ali ne tajne) ili informacije sa oznakom tajnosti na nacionalnom nivou. Pomenute restrikcije su dokumentovane u akcionom planu privremene akreditacije. Akcioni plan privremene akreditacije pravi DAA za dati IT sistem i dostavlja ga e fu programera i vlasniku sistema, zajedno sa pismom o privremenoj akreditaciji. Akcioni plan sadri: 1) Kritine misije koje zahtevaju da operativnost sistema, 2) l istu pojedinih potrebnih korektivnih akcija koje pokazuju da su potrebne kontrol e sigurnosti implementirane korektno i da su efikasne, 3) dogovoreni rok za ostv arivanje planiranih korektivnih akcija, 4) izvore neophodne za pravilno kompleti ranje korektivnih akcija, 5) operativne restrikcije koje su zavedene, da bi se s manjio rizik tokom privremene akreditacije. [NIST Specijalna publikacija 800-37] 63

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema 4.4 Faza post-akreditacije Svrha faze postakreditacije je da se nadgleda status datog IT sistema, kako bi s e utvrdilo da li ima znaajnih izmena u konfiguraciji sistema, (npr. modifikacije u hardveru, softveru ili firmveru sistema) ili znaajnih izmena u radnom okruenju i okruenju moguih pretnji, koje mogu imati uticaje na tajnost, integritet i/ili ras poloivost informacija koje se obrauju, uvaju ili prenose od strane sistema. Aktivno st nadgledanja je neophodna, kako bi se osiguralo uvanje prihvatljivog nivoa preo stalog rizika sistema. Kada promene sistema ili promene operativnog okruenja ili okruenja pretnji za sistem, znaajno narastu u odnosu na zatitu sistema, poinju aktiv nosti vezane za reakreditaciju. Zahtevi reakreditacije mogu varirati od agencije do agencije i mogu biti uslovljeni odreenim vremenskim rokovima ili odreenim dogaa jima. Da bi se definisali zahtevi za reakreditaciju, treba se pozivati na postoj ee zakone, regulacije, direktive ili politike. Faza postakreditacije ima tri zada tka: Auriranje procene rizika; Auriranje opisa sistema i okruenja Reakreditacija; Gaenje sistema Faza postakreditacije je kontinualan proces, koji je neophodan, da bi se ukazalo na dinamiku prirodu misija agencije i na brze promene tehnologije koriene u agenci ji za podrku tih misija. Sledea sekcija sadri opis svih zadataka postakreditacije i pridodatih podzadataka. ZADATAK 13: AURIRANJE PROCENE RIZIKA Cilj ovog zadatka j e da se kontinualno nadgleda i revidira otvoreni izvor, kao i ostale mogue pretnj e i ranjive informacije, da bi se procenio uticaj potencijalnih, novih pretnji i ranjivosti sistema i njegovog operativnog okruenje. Novo identifikovane pretnje i ranjivosti mogu zahtevati reviziju 1) nivoa brige za tajnost, integritet, rasp oloivost i izloenost sistema, 2) kontrola sigurnosti i 3) nivoa sertifikacije, kak o bi se osigurala adekvatna zatita sistema. PODZADATAK 13.1: Nadgledanje relevantnih izvora novih pretnji i ranjivosti, koje su od znaaja za a kreditovanje IT sistema i/ili njegovo operativno okruenje. SAVET NAPOMENA: Nove pretnje i ranjivosti mogu uticati na kontrole sigurnosti akreditovanog IT sistema. Kontrole mogu zahtevati doradu, aur iranje, pojaavanje ili reprojektovanje. Postoje brojni javni (otvoreni) izvori za pretnje, ranjivost i informacije o kontramerama. Ovi izvori obezbeuju kontrolne liste, savete sistem administratorima, detaljne informacije o odreenim pretnjama, ranjivosti, kao i kontramerama i alatima za zatitu. [NIST Specijalna publikacija 800-18, 800-37] 64

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema PODZADATAK 13.2: Po potrebi aurirati izvetaj o proceni rizika. [NIST Specijalna publikacija 800-18, 800-37] ZADATAK 14: AURIRANJE SISTEMA I OKRUENJA Cilj ovog zadatka je da se paljivo prate s ve modifikacije IT sistema ili njegovog operativnog okruenja. DAA, ef programera, i vlasnik sistema moraju biti strogi u odravanju stanja sigurnosti sistema. Prome ne sistema mogu uticati na nain rada kontrola sigurnosti ili mogu kreirati nove r anjivosti. Isto tako, okruenje obezbeuje odreeni stepen zatite sistema i mora biti s talno nadgledano u odnosu na promene, koje mogu uticati na stanje sigurnosti sis tema. Praksa strogog upravljanja konfiguracijom obezbeuje da se sve promene siste ma dokumentuju to je prvi korak u proceni potencijalnog uticaja ovih promena na z atitu sistema. Mora biti omogueno konstantno poboljavanje sistema, bez neophodnog p okretanja procesa reakreditacije. Da bi se ostvariio ovaj tip kontrolisane prome ne, potrebno je da se svaka modifikacija, predloena ili stvarna, procenjuje u odn osu na mogui uticaj na zatitu sistema. Posto se izvri modifikacija sistema i izvr ve rifikacija da promena nema uticaja na zatitu sistema, aurira se plan sigurnosti na odgovarajui nain. Ako postoji uticaj na zatitu sistema, inicira se reakreditacija. PODZADATAK 14.1: Pregled svih modifikacija datog IT sistema ili njegovog operativnog okruenja, da bi se odredio potencijalni uticaj tih modifikacija na zatitu. SAVET NAPOMENA: Sve predloene modifikacije akreditovanog sistema ili njegovog okruenja mogu dezavuisati originalne akreditacije sistema. K oristei upravljanje konfiguracijom ili proces kontrola promena, smanjuje se moguno st da modifikacije sistema ili okruenja (prostorije, zgrade) ugroze tajnost, inte gritet, ili raspoloivost sistema. Proces upravljanja konfiguracijom, pomae i odrava nju osnovne sigurnosti sistema, jer kontrolie i nadgleda promene sistema, i ident ifikuje trenutak, kada promene zahtevaju resertifikaciju ili reakreditaciju. Uko liko je potrebno, zahtevi za promenu se odbacuju sve dok se ne ugrade odgovarajue promene u zatiti. Kada su napravljene promene u akreditovanom sistemu, potrebno je odrediti najbolji nain za implementaciju novog hardvera, firmvera, ili softver a da bi se osigurala tajnost, integritet, i / ili raspoloivost sistema. Kada je t o potrebno, razvija se plan tranzicije da bi se izvrila migracija sistema na vrem e i sigurno. PODZADATAK 14.2: Po potrebi aurirati plan sigurnosti. [NIST Specijalna publikacija 800-18, 800-37] ZADATAK 15: REAKREDITACIJA 65

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema Cilj ovog zadatka je da se identifikuju znaajne promene sistema ili njegovog oper ativnog okruenja, koje obavezno zahtevaju reakreditaciju. DAA, u konsultaciji sa e fom programera ili vlasnikom sistema, odreuje uslove pod kojim sistem mora biti r eakreditovan. Reakreditacija moe biti uslovljena odreenim dogaajima ili vremenskim takama u zavisnosti od zakona, regulacija, direktiva, instrukcija, ili politika k oje diktiraju takve aktivnosti. Na primer, OMB cirkularno pismo A-130 zahteva re akreditaciju svake tri godine ili kad god se dese znaajne promene sistema; neke a gencije mogu zahtevati reakreditaciju godinje. U svakom sluaju, reakreditacija sis tema poinje fazom predsertifikacije i sadri sve one zadatke, koje je trebalo izvrit i tokom originalnog C&A procesa. U zavisnosti od prirode i dometa modifikacija s istema i njegovog odgovarajueg okruenja, znaajan deo originalne sertifikacione doku mentacije i ST&E rezultati se mogu primeniti i sada. Ponovno korienje prethodne s ertifikacione evidencije je efikasan metod redukovanja cene formiranja nove doku mentacije, tokom procesa reakreditacije. PODZADATAK 15.1: Odreivanje potreba za reakreditaciju dotinog IT sistema. SAVET NAPOMENA: Postoji mnogo promenjivih parametara koje mogu zahtevati reakreditaciju IT sistema. Najei razlog za reakreditaciju IT sistema je promena osnova sistema,promenom okruenja koji utie na zatitu. Zato se u postupk u reakreditaciju treba koncentrisati na promene koje su se dogodile od prvobitne akreditacije. Sledei spisak je delimina lista dogaaja koji utiu na zatitu, a mogu za htevati reakreditaciju sistema: 1) promena nivoa brige za tajnost, integritet i / ili raspoloivost, 2) dodaci, modifikacije ili upgradi hardvera, softvera, ili f irmvera koji zahtevaju promene proverenih kontrola sigurnosti, 3) promena pretnj i, koje kreiraju novu osetljivost sistema, to rezultuje poveanjem rizika, 4) prome ne misije, 5) probijanje sigurnosti, probijanje integriteta sistema, ili neobine situacije koje ponitavaju akreditaciju stvaranjem rupa u projektovanoj zatiti i iz lau sistem ranjivosti, 6) znaajne promene u fizikoj infrastrukturi, 7) znaajne prome ne u radnim procedurama, 8) promene konfiguracije sistema, 9) ukljuivanje dodatni h delimino akreditovanih sistema, rezultati praenja i eksterne analize. Kada se id entifikuje potreba za reakreditacijom, potrebno je vratiti se na fazu predsertif ikacije. [NIST Specijalna publikacija 800-37] ZADATAK 16: GAENJE SISTEMA Cilj ovo g zadatka je da osigura da je sistem dostigao kraj svog ivotnog ciklusa i da, poto je identifikovan za gaenje, bude uklonjen iz operativnog okruenja i odloen na sigu ran nain. Postoje tri glavne oblasti koje moraju biti razmotrene i uzete u obzir, kada se sistem identifikuje za eliminaciju: 1) arhiviranje informacija, 2) odla ganje hardvera, firmvera i softvera, 3) ienje medija sa podacima. 66

NACRT Uputstva za Sertifikaciju bezbednosti i Akreditaciju IT sistema PODZADATAK 16.1: Odlaganje sistema na siguran nain u skladu sa politikom i procedurama agencije. SAVET NAPOMENA: Najee ne postoji definitivan kraj ivotnog

ciklusa sistema. Sistemi evoluiraju ili prelaze u sledeu generaciju, kao rezultat promenjenih zahteva ili napretka tehnologije. Trebalo bi, da planovi sigurnosti kontinualno evoluiraju sa sistemom. ak i u situacijama gde je sistem identifikov an za prestanak rada (npr, AUTODIN TO DMS tranzicija), ako je plan sigurnosti bi o odravan aurnim, mnoge informacije u vezi sa okruenjem, upravljanjem ili radom e bi ti jo uvek relevantne i mogu biti korisne u razvoju plana sigurnosti za naredni s istem. Arhiviranje informacija. Kada se vri arhiviranje informacija, agencije tre ba da razmotre dodatne metode za pretraivanje informacija u budunosti. Iako je ele ktronske informacije lake pretraiti i smestiti, tehnologija korienja za njeno uvanje moe u budunosti biti prevaziena i nedostupna. U procesu gaenja IT sistema, treba raz motriti zakonske zahtevi za zadravanje zapisanih. Hadrver, firmvere i softver. Ha drver, firmvere i softver moe biti prodat, poklonjen ili uniten. Retko postoji pot reba da se uniti hardver, osim za neke memoriske medije koji sadre tajne informaci je a ne mogu se isprazniti, tj. potpuno oistiti bez unitenja. Odlaganje softvera m ora odgovarati licenci ili drugim dogovorima sa onima koji su ga razvili. ienje med ija. Sklanjanje informacija sa memoriskih medijuma se zove ienje. Razliite metode ienj obezbeuju razliite nivoe sigurnosti. Moe se napraviti razlika izmeu ienja informacija i uklanjanja informacija. ienje informacije je sklanjanje osetljivih podataka sa me moriskog ureaja na kraju perioda obrade na takav nain da postoji sigurnost, propor cionalna osetljivost tih podataka da se podaci ne mogu rekonstruisati korienjem no rmalnih mogunosti sistema (npr, upotrebom tastature). Uklanjanje informacije je s klanjanje osetljivih podataka sa memoriskog ureaja na kraju perioda obrade na tak av nain da postoji sigurnost, proporcionalna osetljivost tih podataka da se podac i ne mogu rekonstruisati korienjem standardne laboratoriske tehnike. Degausing, pr episivanje i unitenje medija su neke od metoda uklanjanja informacija. Degausing je proces magnetnog brisanja medija. Prepisivanje je proces kada se beznaajni pod aci prepiu preko osetljivih podataka. Medijumi mogu biti uniteni na sledee naine: 1) unitenjem u profesionalnim ureajima za unitenje metala (izlivanje, dezintegracija, pulverizacija), 2) spaljivanjem, 3) premazivanje magnetnih diskova abrazivnim s ubstancama. [NIST Specijalna publikacija 800-37] 67