Metodologije za razvoj sigurnog softvera

Izvor: SIS Wiki

Skoči na: orijentacija, traži

Članovi tima:

Lovel Mimica
Marin Barišić

--Tkisason 10:34, 30. listopada 2015. (CET) --Marin Barisic 00:09, 13. studenog 2015. (CET)

Sadržaj

Uvod

Security Assurance Maturity Model (u nastavku SAMM) predstavlja normativni model ugradnje informacijske sigurnosti u organizacije koje se bave razvojem software - a[1] . Drugim riječima predstavlja skup smjernica čijom implementacijom se potonje ogranizacije dovode u stanje posjedovanja organizacijske sposobnosti da sistematično, efikasno i efektivno razvija sigurni software.

Kao dva temeljna načina segmentacije modela se ističe segmentacija s obzirom na poslovnu funkciju te s obzirom na razinu odnosno nivo zrelosti implementacje.

Segmentacija s obzirom na poslovnu funkciju dijeli model u četiri temeljne cjeline, od kojih se svaka odnosi na jednu poslovnu funkciju relevantnu za proces razvoja software – a koji se provodi u organizaciji. Shodno sa time se u okviru SAMM ističu četiri temeljne cjeline:

1. Governance (Upravljanje)

Odnosi se na aktivnosti koje proizlaze iz generalnog upravljanja organizacijom, a relevantne su za procese razvoja software – a. Tako se u tom kontekstu ističu smjernice iz sljedećih aspekata upravljanja organizacijom:

1. 1. Strategija i metrika

1. 2. Organizacijska politika i usklađivanje s normama

1. 3. Edukacija i usmjeravanje kadrova

2. Construction (Izrada)

Odnosi se na aktivnosti koje se manifestiraju za vrijeme samog procesa razvoja software – a, pa se tako shodno sa time ističu tri skupine smjernica vezanih uz tri aspekta izrade software – a:

2. 1. Procjena prijetnji

2. 2. Sigurnosni zahtjevi

2. 3. Sigurna arhitektura

3. Verification (Verifikacija)

Odnosi se na aktivnosti koje se manifestiraju nakon što je software izrađen, odnosno u toku njegove verifikacije. U tom kontekstu razlikujemo tri skupine smjernica, a to su smjernice iz kategorija:

3. 1. Revizija dizajna programskog sustava

3. 2. Revizija koda

3. 3. Testiranje sigurnosti

4. Deployment (Uvođenje)

Odnosi se na aktivnosti nakon isporuke razvijenog software – a kupcu, odnosno na aktivnosti podrške istome u kontekstu sigurnosti software – a kojeg je kupio. Tako u okviru ove cjeline razlikujemo sljedeće aspekte:

4. 1. Upravljanje ranjivostima

4. 2. "Učvrščivanje" runtime okruženja

4. 3. Operativno osposobljavanje

Sa druge strane, SAMM – ove smjernice se mogu grupirati i prema hijerarhijskoj razini zrelosti implementacije modela kojem organizacija teže. Međutim, treba istaknuti da takva podjela nije isključiva sa prethodnom, već bi se prije moglo reći da joj je komplementarna (nadopunjujuća). Konkretnije, nakon što smjernice bivaju podijeljene u prethodno definirane skupine (gdje se svaka skupina odnosi na jedan od tri aspekta neke od četiri poslovne funkcije) iste se dalje dijele s obzirom na razinu primjene. Tako razlikujemo četiri temeljne razine primjene SAMM – a u organizaciji:

0. Nulta razina

Podrazumijeva situaciju u kojoj organizacija nije implementirala niti jednu smjernicu koju model sugerira te se može reći da predstavlja početnu točku sa koje organizacija kreće u implementaciju modela.

1. Prva razina

Predstavlja situaciju u kojoj organizacija posjeduje razumijevanje i ad hoc izvršavanje aktivnosti ugradnje sigurnosti u razvijane software - e, međutim još se uvijek radi o nekoj osnovnoj (relativno niskoj) razini.

2. Druga razina

Podrazumijeva situaciju u kojoj organizacija efikasno i efektivno provodi aktivnosti ugradnje sigurnosti u software – e koje razvija. Podrazumijeva implementaciju sugeriranih smjernica i aktivnosti prve i druge razine.

3. Treća razina

Podrazumijeva situaciju u kojoj organizacija posjeduje kompresivno majstorstvo u kontekstu ugradnje sigurnosti u software – e koje izrađuju te da bi bila ostvarena kao nužjni preduvijeti se ističu implementacije prve dvije razine te nakon toga i cijele treće razine.

U ovom se kontekstu još mogu istaknuti četiri dodatne međurazine, konkretno nulta+, prva+, druga+ i treća+. Svaka od potonjih podrazumijeva da je organizacija u cijelosti implementirala razinu zrelosti koja joj odgovara prvom dijelu imena, dok znak „+“ ukazuje na to da je uvela i određene dodatne elemente modela (ili pak van modela) koje je komparativno stavljaju ispred organizacija koje su implementirale isključivo set smjernica neke razine i ništa više od toga.

U nastavku su opisani sve skupine smjernica modela, u prvom redu grupirane prema poslovnoj funkciju, a u drugom s obzirom na hijerarhijsku razinu zrelosti.

Slika 1. Hijerarhijska struktura SAMM-a

Governance (Upravljanje)

Strategija i metrika

Razina 1

Da bi se postigla razina 1. ovog aspekta SAMM – a, u osnovi je potrebno uspostaviti unificiranu strategiju upravljanja sigurnosti software – a koji se razvija unutar organizacije. Konkretnije, primjena ove razine bi trebala rezultirati identifikacijom i izlistom najznačajnijih rizika sa kojima se organizacija suočava, a iz konteksta informacijskih rizika software – a koje ista razvija. Dalje bi trebala rezultirati i planom adresiranja identificiranih rizika, odnosno sigurnosnih unapređenja razina primjene različitih aspekata SAMM - a, kao i razumijevanjem većine članova organizacije kako će se vremenski dotični plan sprovoditi.

1. Procijeniti generalni poslovni rizik u kontekstu sigurnosti

2. Kreirati i izvršavati program unapređenja razine sigurnosti

Kao temeljna izvorišta troškova uvođenja i održavanja ove razine, se ističu izrada i održavanje spomenute liste rizika te periodna (kao npr kvartalna, polugodišnja i sl) evaluacija programa unapređenja sigurnosti (u smislu provjere da li su ostvareni postavljeni ciljevi i sl).

Razina 2

Da bi se postigla 2. razina ovog aspekta SAMM – a, u osnovi je potrebno biti u mogućosti komparativno mjeriti vrijednost informacijske i software – ske imovine i na temelju toga određivati pripadajuće razine rizika (i tolerancije istog). Konkretnije, primjena ove razine bi trebala rezultirati organizacijskim znanjem i razumijevanjem (dakle prisutnim kod gotovo svih članova iste) sigurnosnog aspekta svakog segmenta informacijske i software - ske imovine, kao i relativno visokom informiranosti svih značajnih stakeholdera o rizicima koji proizlaze iz software – a koje organizacija razvija. Također bi primjena ove razine trebala rezultirati i praksom kreiranja planova na razini jednog projekta, koji adresiraju sigurnosna pitanja istog.

1. Kategorizacija podataka i software – a s obzirom na rizik koji generiraju

2. Postavljanje i mjerenje sigurnosnih ciljeva za svaku (prethodno postavljenu) kategoriju podataka i software - a.

Kao temeljna izvorišta troškova uvođenja i održavanja ove razine, se ističu izrada ili nabava kategorizacijskog modela za svrstavanje podataka i software – a, s obzirom na njihov rizik. Također se u ovom kontekstu može istaknuti i trošak rasta radnog opterećenja radi veće zrnatosti pri određivanju i adresiranju sigurnosnih rizika.

Razina 3

Da bi se postigla 3. razina ovog aspekta SAMM – a, u osnovi je potrebno, na upravljačkoj razini, povezati ulaganja u sigurnost sa ostalim relevantnim poslovnim indikatorima. Konkretnije, primjena ove razine bi trebala rezultirati procjenom povijenih (implicitnih i eksplicitnih) troškova proizašlih iz zanemarivanja sigurnosnih aspekata razvijanih software – a, kao i procjenom potrebnih ulaganja u sigurnost i mogućih gubitaka u slučaju izbjegavanja istog na razini svakog projekta te provedbama analiza potonjih varijabli na razini industrije u kojoj organizacija posluje (s ciljem benchmarkinga). Navedeno bi trebalo poslužiti i kao informacijski input za donošenje odluka oko ulaganja u sigurnost razvijanih software – a.

1. Provedba periodičnih industrijskih analiza i benchmarkinga (formalnog ili neformalnog)

2. Prikupljanje podataka relevantnih za metriku povijesnih ulaganja u sigurnosti (i utjecaja istih na druge poslovne pokazatelje)

Kao temeljna izvorišta troškova uvođenja i održavanja ove razine se ističu provedba ili nabava rezultata spomenute industrijske analize, kao i porast radnog opterećenja radi dodatnih aktivnosti procjene, praćenja i analize (potrebnih i prošlih) ulaganja te implikacija istih na poslovanje.

Organizacijska politika i usklađenost s normama

Razina 1

Da bi se postigla 1. razina ovog aspekta SAMM – a, u osnovi je potrebno postići spoznaju i razumijevanje temeljnih internih i eksternih sigurnosnih normi (u širem smislu riječi) sa kojima se organizacija treba uskladiti. Konkretnije, primjena ove razine bi trebala rezultirati povećanjem nastojanja da se „pozitivno završe“ nadzori od strane trećih strana (vezanih uz usklađenost sa različitim normama), kao i prikladno mobilizacijom resursa usmjerenih na postizanje usklađenosti i to sortiranom prema važnosti određene norme. Primjena bi također trebala rezultirati i pravovremenom spoznajom o novim zahtjevima regulatornih i normativnih tijela vezanih za informacijsku sigurnost.

1. Identifikacija i praćenje eksternih normi vezanih za sigurnost software – a, a i informacijskih sustava generalno

2. Izgradnja i održavanje internih smjernica za postizanje usklađenosti sa skupom relevantnih normi

Kao temeljna izvorišta troškova uvođenja i održavanja ove razine se ističu izrada i kontinuirano održavanje „liste kontrolnih točaka“ koje ukazuju da li je postignuta određena normativna usklađenost ili ne.

Razina 2

Da bi se postigla 2. razina ovog aspekta SAMM – a, u osnovi je potrebno postaviti okosnicu normi za koju bi bilo dobro da se poštuje u kontekstu procesa razvoja software – a, kao i postići razumijevanje rizika na razini projekta zasebno ako se ista ne bi ispoštovala. Konkretnije, primjena ove razine bi trebala rezultirati relativno dobrom upoznatošću članova projektnih timova sa time što se od njih očekuje u kontekstu normativne usklađenosti, kao i u kontekstu sigurnosti software – a kojeg razvijaju, kao i upoznatosti managerskih kadrova vezanih za određeni proizvod ili projekt sa specifičnim poslovnim rizicima koji bi se mogli javiti u slučaju neusklađenosti sa određenim normama. Također bi se navedeno trebalo generalno rezultirati jednim sistematičnim i optimiziranim organizacijskim pristupom ka postizanju normativne usklađenosti, skupa sa kontinuiranim traženjem mogućnosti sigurnosnih unapređenja razvijanih software – a.

1. Kreiranje internih politika i standarda vezanih uz sigurnost software – a i usklađenost sa eksternim normama.

2. Uvesti praksu provjere usklađenosti svakog projekta sa postavljenim politikama i standardima

Razina 3

Da bi se postigla 3. razina ovog aspekta SAMM – a, u osnovi je potrebno postaviti obavezu poštivanja određenih politika i standarda za svaki projekt, kao i vršiti provjeru istog. Konkretnije, primjena ove razine bi trebala rezultirati postavljenom razinom rizika (na razini organizacije) koji proizlazi iz normativnih neusklađenosti, a koji je organizacija spremna prihvatiti. Na temelju istog bi se trebali postavljati konkretni zahtjevi na razini projekta kojima se treba udovoljiti da bi isti mogao biti „prolazan“, kao i (na razini organizacije) uspostaviti efikasan proces provjere dotične „prolaznosti“. Također bi se kao rezultat primjene trebala javiti i evidencija kretanja razine usklađenosti određenog projekta kroz prošlo vrijeme.

1. Kreiranje skupa nužnih uvjeta (iz konteksta informacijske sigurnosti) kojima projekt mora udovoljiti

2. Dizajniranje efikasnog poslovnog procesa kojim će se provjeravati usklađenost projekata sa postavljenim uvjetima (drugim riječima, izbjegavanje ad – hoc provjera za svaki projekt zasebno)

Kao temeljna izvorišta troškova uvođenja i održavanja ove razine se ističu dizajn ili nabava „već dizajniranog“ spomenutog poslovnog procesa, kao i kontinuirano održavanje skupa nužnih uvjeta.

Edukacija i usmjeravanje kadrova

Razina 1

Da bi se postigla 1. razina ovog aspekta SAMM – a, u osnovi je potrebno developerskim kadrovima dati pristup edukativnim resursima vezanim uz tematiku razvoja sigurnog software – a. Konkretnije, primjena ove razine bi trebala rezultirati povećanom upoznatosti developera sa spomenutom tematikom te nastojanjima da razvijani software – i budu u skladu sa temeljnim najboljim praksama iz aspekta informacijske sigurnosti. Također bi trebala rezultirati i relativno ujednačenim skupom znanja o informacijskoj sigurnosti među tehničkim kadrovima, kao i prisutnosti mogućnosti lake provjere dotičnih znanja.

1. Provedba treninga za postizanje temeljne upoznatosti sa tehničkim aspektima informacijske sigurnosti

2. Izrada i održavanje skupa tehničkih smjernica za razvoj sigurnih software – a

Kao temeljna izvorišta troškova uvođenja i održavanja ove razine se ističu provedba spomenutog treninga kadrova te kreiranje i održavanje spomenutog skupa smjernica.

Razina 2

Da bi se postigla 2. razina ovog aspekta SAMM – a, u osnovi je potrebno educirati sve djelatnike uključene u proces razvoja software – e, o temama iz područja informacijske sigurnosti koja su relevantna za njihovu ulogu u dotičnom procesu. Konkretnije, primjena ove razine bi trebala rezultirati upoznatosti svih aktera u procesu razvoja software – e sa kritičnim točkama svake etape procesa razvoja software – a, koje (ako nisu adekvatno adresirane) mogu dovesti do ranjivosti bilo na razini proizvoda, razini dizajna ili razini samog koda te također i dubljim razumijevanjem sigurnosnih pitanja generalno (i generalnim proaktivnijim pristupom rješavanju istih). Primjena bi isto tako trebala rezultirati i izraženim planovima za adresiranje svake konkretne potencijalne ranjivosti kao i kreiranim mjernim alatom (u širem smislu riječi) za određivanje da li je određena kritična točka, u određenoj etapi procesa, na adekvatan način adresirana.

1. Provedba treninga (vezanih uz razvoj sigurnog software – a) djelatnika uključenih u razvojni proces, ali specifičnih za fazu procesa u kojoj određeni djelatnik ima ulogu

2. Interno ili eksterno pribaviti edukatore iz područja informacijske sigurnosti te ih „staviti na raspolaganje“ projektnim timovima

Kao temeljna izvorišta troškova uvođenja i održavanja ove razine se ističu izrada ili nabava skupa edukativnih resursa za provedbu navedenih treninga te trošak rada spomenutih edukatora.

Razina 3

Da bi se postigla 3. razina ovog aspekta SAMM – a, u osnovi je potrebno postaviti sveobuhvatni trening iz informacijske sigurnosti kao obavezan za sve kadrove iz područja razvoja software – a, kao i uvesti certificiranje posjedovanja znanja o određenom segmentu tog područja. Konkretnije, primjena navedene razine bi trebala rezultirati i efikasnim otklanjanjem ranjivosti iz ranije razvijenih, kao i iz trenutno razvijanih software –a, kao i brzim razumijevanjem novih prijetnji te kvalitetnim adresiranjem istih. Također bi se kao rezultat trebali javiti i kvalitetan sustav procjene djelatnika u kontekstu njihovih znanja i vještina sa područja informacijske sigurnosti te sustav nagrađivanja unapređenja istih.

1. Kreiranje portala službeno namijenjenog podršci ugrađivanja sigurnosti u razvijane software – e (koji bi sadržavao različite smjernice, najbolje prakse, forume i ostale korisne materijale vezane za informacijsku sigurnost)

2. Uspostava sustava educiranja i certificiranja za vršenje različitih uloga u procesu razvoja (sigurnog) software – a

Kao osnovna izvorišta troškova uvođenja i održavanja ove razine se ističu izrada ili nabava sustava za certifikaciju (i edukaciju) djelatnika te povećano radno opterećenje djelatnika iz funkcije upravljanja ljudskim resursima koji bi trebali raditi u okviru istoga, održavanje spomenutog portala kao i spomenuto nagrađivanje djelatnika (koji ostvare uspjehe u kontekstu razvoja znanja i vještina)

2. Izrada (Construction)

Procjena prijetnji

Razina 1

Da bi se postigla 1. razina ovog aspekta SAMM – a, u osnovi je potrebno identificirati i razumjeti najznačajnije prijetnje iz segmenta informacijske sigurnosti na generalno organizacijskoj razini, kao i na razini svakog projekta zasebno. Konkretnije, primjena navedene razine bi trebala rezultirati spoznajom i razumijevanjem ključnih faktora iz konteksta informacijske sigurnosti, koji mogu uzrokovati probleme, kao i upoznatosti projektnih timova sa prijetnjama na razini specifičnog projekta u koji su uključeni te generalnim „skladištem“ prijetnji za organizaciju iz dotičnog konteksta.

1. Izrada i održavanje skupa prijetnji na razini svakog razvijanog software – a zasebno

2. Izraditi profile potencijalnih napadača

Kao osnovna izvorišta troškova uvođenja i održavanja ove razine se ističu izrada dotičnog skupa prijetnji i profila napadača.

Razina 2

Da bi se postigla 2. razina ovog aspekta SAMM – a, u osnovi je potrebno unaprijediti prethodno uspostavljenu procjenu prijetnji i povećati detaljnost i zrnatost u kontekstu identificiranja istih za svaki projekt zasebno. Konkretnije, primjena navedene razine bi trebala rezultirati relativno detaljnom i zrnatom svjesnošću o najznačajnijim prijetnjama za svaki projekt specifično, kao i postavljenom okosnicom za donošenje odluka unutar razvojnog tima o prioritetiziranju napora da se određena prijetnja adresira.

1. Izrada abuse – case modela u okviru svakog projekta

2. Kreirati i uvesti sustav mjerenja i komparacije prijetnji, s obzirom na različite atribute istih

Kao osnovno izvorište troškova uvođenja i održavanja ove razine se ističe porast radnog opterećenja na projektima radi izrade i održavanja (proširenog) modela prijetnji i napadaća.

Razina 3

Da bi se postigla 3. razina ovog aspekta SAMM – a, u osnovi je potrebno svakoj prijetnji pridodati određenu kontrolu koja istu neutralizira (uključujući i prijetnjama koje se odnose na nabavljene gotove software – ske komponente). Konkretnije, primjena navedene razine bi trebala rezultirati dubokim razumijevanjem skupa prijetnji na razini svakog projekta, razvijenim skupom kontrola kojima se adresira svaka prijetnja zasebno, kao i dokumentacijom koja se odnosi na aktivnosti iz ovog konteksta također na razini svakog projekta zasebno.

1. Eksplicitno evaluirati rizik nabavljenih gotovih software – skih komponenti

2. Elaborirati skup prijetnji, skupa sa adresirajućim kontrolama

Kao osnovna izvorišta troškova uvođenja i održavanja ove razine se ističu rast radnog opterećenja uzrokovan izradom detaljnijih modela prijetnji i profila napadač, kao i proces analize nabavljenih komponenti s ciljem otkrivanja njihovih ranjivosti.

Sigurnosni zahtjevi

Razina 1

Da bi se postila 1. razina ovog aspekta SAMM – a, u osnovi je potrebno uvesti eksplicitno uzimanje u obzir sigurnosnih pitanja tokom etape specifikacije zahtijeva software – a. Konkretnije, primjena navedene razine bi trebala rezultirati općenito definiranom povezanosti aktivnosti iz procesa razvoja software – a sa aktivnosti iz područja upravljanja poslovnim rizicima, kao i ad – hoc (dakle nesistematičnim) praćenjem industrijskim najboljim praksama u kontekstu postavljanja sigurnosnih zahtijeva. Također bi se kao rezultat trebala isticati i svjesnost svih projektnih stakeholdera oko mjera iskorištenih da bi se ublažili sigurnosni rizici koje razvijani software generira.

1. Deriviranje sigurnosnih zahtijeva iz software –ovih poslovnih zahtjeva

2. Postaviti neke od industrijskih najboljih praksi kao sigurnosne zahtjeve

Kao osnovno izvorište troškova uvođenja i održavanja ove razine se ističe porast radnog opterećenja radi dodavanja (i posljedično ispunjavanja) novih (sigurnosnih) zahtijeva software – u koji se razvija.

Razina 2

Da bi se postigla 2. razina ovog aspekta SAMM – a, u osnovi je potrebno povećati zrnatost i detaljnost postavljenih sigurnosnih zahtijeva te iste derivirati i iz poslovnih zahtijeva i iz poznatih rizika sa kojima se software suočava . Konkretnije, primjena navedene razine bi trebala rezultirati detaljnim razumijevanjem mogućih vektora napada, kao i postavljanje sigurnosnih zahtijeva usmjerenih neutraliziranju istih. Također bi trebala rezultirati porastom sposobnosti članova projektnog tima da donose odluke vezane uz ugrađivanje sigurnosnih svojstava u software. Isto tako bi i svih „umiješani“ u specificiranje zahtjeva trebali biti bolje informirani o tome kako izbjeći postavljanje onih zahtjeva koji bi mogli dovesti do sigurnosnih ranjivosti.

1. Kreirati matricu prava pristupa različitih aktera koji koriste software, njegovim resursima i funkcionalnostima

2. Specificirati sigurnosne zahtjeve na temelju identificiranih sigurnosnih rizika

Kao osnovno izvorište troškova primjene i održavanja ove razine se ističe porast radnog opterećenja uzrokovanom kreiranjem i održavanjem skupa vektora napada, detaljnijeg postavljanja sigurnosnih zahtjeva kao i izrade matrice prava pristupa.

Razina 3

Da bi se postigla 3. razina ovog aspekta SAMM – a, u osnovi je potrebno specifikaciju sigurnosnih zahtijeva učiniti obaveznom za sve softvare – e koji se razvijaju, kao i za gotove software – ske komponente koje se nabavljaju. Konkretnije, primjena navedene razine bi trebala rezultirati formaliziranim skupom sigurnosnih zahtijeva koji se očekuju od komponenata koje se nabavljaju, kao i centraliziranim informacijskim centrom koji sadrži podatke o naporima uloženima u sigurnosni aspekt svakog razvijanog software – a. Također bi iz navedenog trebala proizači i organizacijska sposobnost da optimalno dodijeli resurse projektima s obzirom na traženu razinu sigurnosnih zahtijeva.

1. Uvođenje sigurnosnih zahtijeva u ugovore sa dobavljačima software – skih komponenti

-2. Proširenje programa nadzora ispunjenja sigurnosnih zahtijeva kod razvijanih software - a

Kao osnovna izvorišta troškova primjene i održavanja ove razine se ističu rast cijena nabavljenih software – skih komponenti (radi povećanih zahtijeva prema dobavljačima) te porast radnog opterećenja na projektima radi nužnosti udovoljavanja širem skupu (sigurnosnih) zahtijeva.

Sigurna arhitektura

Razina 1

Da bi se postigla 1. razina ovog aspekta SAMM - a, u osnovi je potrebno u etapu dizajna arhitekture programskog sustava uvesti i razmatranje smjernica vezanih uz siguran arhitekturalni dizajn. Konkretnije, navedeno bi trebalo rezultirati prevencijom neprikladnih međukomponentnih ovisnosti, kao i jednokratnih implementacijskih rješenja te također i uvođenjem uhodanog protokola za ugrađivanje sigurnosnih mehanizama u dizajn sustava. Također bi trebalo rezultirati upoznatošću relevantnih projektnih stakeholdera sa rizicima koji proizlaze iz korištenja određenih biblioteka, software – skih komponenti i frameworka – a.

1. Kreiranje i održavanje liste preporučenih („poznatih po sigurnosti“) software – skih framework – a

2. Eksplicitno aplicirati načela sigurnog dizajna sustava u software – e koji se razvijaju

Kao temeljna izvorišta troškova primjena i održavanja ove razine se ističu izrada i održavanje navedenog skupa preporučenih framework – a te porast radnog opterećenja na projektima uzrokovan vršenjem analiza i primjene načela sigurnog dizajna programskog sustava.

Razina 2

Da bi se postigla 2. razina ovog aspekta SAMM – a, u osnovi je potrebno usmjeriti dizajn sustava ka korištenju poznatih (i sigurnih) komponenata te primjeni „a priori“ sigurnih koncepata software – skog dizajna. Konkretnije, kao rezultat primjene ove razine bi se trebali javiti detaljna mapa software – ovih resursa, povezanih sa korisničkim ulogama koje iste koriste (s ciljem što bolje kategorizacije istih). Također bi se trebalo javiti i povećanje ponovne iskoristivosti (sigurnih) gradbenih blokova software – a te poticanje što veće primjene istih.

1. Identifikacija i „forsiranje korištenja“ sigurnih servisa i infrastrukture

2. Identifikacija sigurnih uzoraka dizajna arhitekture

Kao temeljna izvorišta troškova primjene i održavanja ove razine se ističu izrada ili nabava primjenjivih uzoraka dizajna te porast radnog opterećenja uzrokovan održavanjem (proširene) matrice prava pristupa.

Razina 3

Da bi se postigla 3. razina ovog aspekta SAMM – a, u osnovi je potrebno uvesti formalnu kontrolu etape dizajna programskog sustava te u okviru iste validirati korištenje sigurnih komponenti. Konkretnije, primjena ove razine bi trebala rezultirati developer – skim framework – om, prilagođenim organizacijskim potrebama, a koji sadrži sigurne ugradbene komponente. Također bi se trebalo javiti i težnja ka proaktivnom djelovanju s ciljem unapređenja sigurnosti za vrijeme razvoja software – a, kao i povećane sposobnosti projektnih stakeholder – a da donose odluke u kontekstu potreba za sigurnim dizajnom software – a.

1. Postavljanje formalnih referentnih modela arhitekture software – a i razvojnih framework – a

2. Validirati primjenu navedenih framework – ova i uzoraka dizajna

Kao temeljna izvorišta troškova primjene i održavanja ove razine se ističu izrada ili nabava spomenutih referentnih modela i framework – ova skupa sa održavanjem istih te porast radnog opterećenja na projektima radi uvođenja validacije njihova korištenja.

--Lovelmimica1 22:28, 21. siječnja 2016. (CET)

Verikifacija (Verification)

Revizija dizajna programskog sustava (Design review)

Razina 1

Kako bi se postigla prva razina potrebno je pružit podršku ad hoc reviziji softver dizajna te kako bi se osiguralo osnovno smanjenje poznatih prijetnji. Da bi postigli taj cilj potrebno je posjedovati visoku razinu razumijevanja arhitekture sustava sigurnosti. Nadalje, od velike važnosti je osposobiti tim koji može sam provjeravati je li struktura rađena po najboljim sigurnosnim praksama. Potreban je jednostavniji proces koji će upravljati projektnim razinama revizije dizajna.

1.Identificirati moguće napade na sučelju

2.Analiza plana u skladu s poznatim sigurnosnim zahtjevima

Troškove za ovu razinu implementacije čine izrada i upravljanje dijagrama arhitekture za svaki projekt i sami troškovi preopterećenja u radu projekta koji je u opticaju zbog provjera od mogućih napada i sigurnosnih uvjeta dizajna

Razina 2

Druga razina implementacije nudi usluge analize odnosno procjene revizije softverskog dizajna u usporebi s najboljim praksama koje su namjenjene za sigurnost softvera. Rezultati koji proizlaze te koji čine samu razinu implementacije govore da treba propisno i konzistentno nuditi procjene revizije sigurnosti same arhitekture. Također potrebno je istaknuti slabosti u ranije izrađenim softverima na kojima se nisu primjenjivale određene sigurnosne mjere. Razumijevanje sudionika projekta u samu srž kako bi omogućili softveru garantiranu zaštitu.

1.Provjera za cjelovito dodjeljivanje sigurnosnog mehanizma

2.Uvesti uslugu revizije dizajna za projektne timove

Troškovi koji proizlaze iz ove faze implementacije uzrokuju okupljanje, treniranje i održavanje tima zaduženog za reviziju dizajna. Nadogradnja dosadašnjih projekata koji su već u funkciji s različitim zabilježenim aktivnostima iz revizije.

Razina 3

Kako bi se realizirala treća razina implementacije revizije dizajna programskog sustava potreno je ispuniti zahtjeve procjene i provjere artefakta koji su prijeko potrebni u razvoju razumijevanja zaštite mehanizama. Takve zahtjeve potrebno je realizirati pogledom na slabe točke unutar sustava kako bi se potaknuo bolji prikaz samog dizajna. Prikazati razinu upoznatosti organizacije o projektima koji se moraju temeljit na normativnoj okosnici sigurnosti same arhitekture. Usporedba među projektima u smislu učinkovitosti i napretku ka smanjenju poznatih slabosti.

1.Izgraditi dijagram protoka podataka za osjetljivije resurse

2.Uspostaviti pravila odnosno granice koje se odnose na reviziju dizajna

Troškovi proizvedeni ovom razinom implementacije odnose se na preopterećenje u radu koji se odnosni na tekuće projekte, zbog održavanja dijagrama protoka podataka. Troškovi organizacije od kašnjenja projekata koji su uzrokovani od strane revizora.

Revizija koda (Code Review)

Razina 1

Prvu razinu implementacije revizije koda opisuje oportunističko traženje osnovnih slabosti unutar strukture koda i drugih visokorizičnih sigurnosnih pitanja. Zahtjevi koji su ključni za ovu razinu implementacije su provjera uobičajenih slabosti koja koje su se otkrile ili su dovele do napada. Propisuje se osnovna provedba revizije za greške unutar koda koje imaju jak utjecaj na sigurnost. Zahtjeva se osnovna razina pisanja koda koja podliježe sigurnosnim normama.

1.Pravljenje revizijske checkliste od poznatih sigurnosnih uvjeta

2.Provedba u dijelove revizije koda koji je visokog rizika

Troškovi su prouzročeni izgradnjom ili dozvola checkliste revizije koda. Također dolazi do preopterećenja u radu kod tekućih projekata zbog provedbe revizije aktivnosti koje utječu na visoki rizik koda

Razina 2

Druga razina implementacije revizije koda je posvećena automatizaciji revizije koda. Naglašava se kako je puno preciznije i efikasnije napraviti reviziju koda automatizacijom tijekom razvoja koda nego kasnije kad je u cijelosti napisan. Ključno je da su programeri u mogućnosti cijelo vrijeme kontrolirati sami svoj kod, odnosno razinu sigurnosti napisanog koda i to ovisno o potrebi ispraviti. Rutinske analize rezultata napisanog koda određenog tima, osigurava određene navike pisanja koda. Nakon što su svi sudionici svjesni stvarnih slabosti to pospješuje bolje rezultate same analize.

1.Upotrebljavanje alata za automatiziranu analizu koda

2.Integriranje analize koda u sami proces razvoja istog

Uzrokovani troškovi ove razine su zbog pretraživanja i odabira pravog rješenja analize koda. Tu se još javljaju inicijalni troškovi i održavanje integracije automatizma pregleda koda. Javljaju se i kod radnog preopterećenja na tekućim projektima zbog automatizacije revizije koda i olakšavanja načina rada.

Razina 3

Treća razina implementacije kako bi se realizirala potrebno je posegnuti za opsežnom revizijom procesa koda kako bi se otkrile sve ranjive razine i specifični rizici pojedinih programskih jezika. Osnovno je za ovu razinu implementacije ispuniti uvijete koji se odnose na povećanje pouzdanja u ispravnost i primjenjivost rezultata analize koda. Ispunjavanje temeljnih uvjeta organizacije koji propisuju očekivane sigurnosne značajke koda. Osposobljavanje projektnog tima koji imaju zadani cilj prosuđivanje razine sigurnosti koda.

1.Prilagođenje analize koda za aplikacijsko specifična pitanja

2.Ostvarivanje unaprijed određenih mjera za reviziju koda

Troškovi koji rezultiraju uvođenjem izrade i održavanja prilagođene provjere revizije koda. Javljaju se troškovi kod preopterećenja u radu revizora koda. Pojavljuju se i troškovi zbog organizacijskih preopterećenja koja uzrokuje odgađanje projekata zbog greške revizora koda.

Testiranje sigurnosti (Security testing)

Razina 1

Prva razina implementacije osposobiti proces koji omogućava osnovne sigurnosne testove bazirane na implementaciji i softverskim zahtjevima. Ključne uvjeti koje je potrebno ostvari kako bi se ispunili uvjeti implementacije podrazumijevaju nezavisno verificiranje očekivanih sigurnosnih mehanizama koji okružuju kritične poslovne funkcije. Visoka razina ustrajnosti kod provođenja sigurnosnog testiranja. Rastući ad hoc paketa sigurnosnog testa za svaki projekt.

1.Izvesti testne slučajeve iz poznatih sigurnosnih zahtjeva

2.Obavljati penetraciju testiranja pri isporuci softvera

Troškovi koje se odnose na ovu razinu implementacije rezultiraju izgradnjom ili licencom testa sigurnosnih slučajeva. Također raspodjela troškova se odnosi i na tekuće projekte kod kojih dolazi do preopterećenja zbog održavanja i razvoja testa sigurnosnih slučajeva.

Razina 2

Druga razina implementacije se odnosi na izradu automatiziranog, učinkovitijeg i potpunijeg sigurnosnog testiranja tijekom razvoja. Osnovno što je ključno kod implementiranja ove razine je dublje i konzistentnije verificiranje sigurnosnih funkcionalnosti softvera. Mogućnost razvojnog tima da može provjeravati vlastiti kod i ispravljanje problema prije isporuke. Sudionici su više svjesni otvorenih prijetnji kod donošenja odluka o prihvaćanju rizika.

1.Implementacija alata za automatiziranje sigurnosno testiranje

2.Integrirano sigurnosno testiranje u razvojnom procesu

Troškovi koji se pojavljuju u drugoj fazi sigurnosnog testiranja su troškovi na istraživanje i odabir automatiziranih opcija testiranja sigurnosti. Inicijalni troškovi i održavanje automatiziranog integriranog sučelja. Ubrajaju se također i troškovi koji su posljedica preopterećenja rada s tekućim projektom zbog automatiziranja sigurnosnog testiranja i samog olakšavanja načina rada.

Razina 3

Treća razina implementacije zahtjeva aplikacijsko specifična sigurnosna testiranja kako bi osigurala osnovnu sigurnost prije isporuke. Elementi koji su ključni na ovoj razini implementacije uključuju široku organizacijsku utemeljenost za očekivane aplikacijske sposobnosti protiv napada. Nadalje potrebno je prilagoditi skup sigurnosnih testova kako bi se poboljšala ispravnost automatiziranih analiza. Projektni timovi koji su svjesni svrhe ciljeva koji služe za otpor napadima.

1.Iskorištavanje aplikacijsko specifičnih automatiziranih sigurnosnih testiranja

2.Formiranje dosljednih pravila odnosno uvjeta koji se moraju zadovoljiti prilikom sigurnosnog testiranja

Troškovi koji nastaju na ovoj razini implementacije mogu se prikazati na izgradnji i održavanju automatiziranog prilagođenog sigurnosnog testiranja. Nadalje, se odnosi na preopterećenje u procesu rada tehničara sigurnosnog testiranja s tekućim projektima. Također dolazi i do preopterećenja u samoj organizaciji koji su nastali odgodom odnosno zbog neuspjeha u reviziji sigurnosnog testiranja.

Uvođenje (Deployment)

Upravljanje ranjivostima

Razina 1

Prva razina implementacije upravljanje ranjivostima osnovno je razumijevanje plan visoke razine kvalitete koji odgovaranja na izvještaj ranjivosti ili incidenata. Ključno je u ovoj razini izraditi jednostavan proces koji bi rukovao najvećim prioritetom ranjivosti ili incidenata. Framework za obavještavanje sudionika i izvještavanje o događajima sa sigurnosnim značajem. Visoka razina izvršavanja zadaća za rukovanje sigurnosnom problematikom.

1.Dodijeliti ulogu osobi u timu koja će se baviti sigurnosnom problematikom

2.Sastaviti neformalni sigurnosno odgovornan tim ili timove

Troškovi upravljanja ranjivostima prve faze su podijeljeni na tekuće varijable projekta koji su napravljeni zbog preopterećenja radnih napora, odnosno zbog dodjeljivanja sigurnosne uloge te radi identificiranja prikladnog tima koji će biti odgovoran za sigurnost.

Razina 2

Druga razina implementacije upravljanja ranjivostima govori o detaljnom opisu očekivanja za odgovorne procese zadužene za unapređenje konzistentnosti i komunikaciju. Osnovni zadatci koje mora ispunjavati ova razina implementacije odnosi se na komunikacijski plan za bavljenje s izvještajima ranjivosti od trećih osoba. Jasan proces za izvršavanje sigurnosnih zakrpa softverskih operatora. Također je potrebno izvršavati formalni proces za praćenje, rukovanje i unutarnju komunikaciju oko incidenata.

1.Izgraditi konzistentan proces koji je zadužen za odgovaranje na incidente

2.Usvojiti sigurnosnu problematiku transparentnog procesa

Troškovi koji spadaju u ovu razinu su samo tekući organizacijski troškovi koji su uzrokovani preopterećenjem zbog odgovora procesa zaduženog za incidente.

Razina 3

Treća razina implementacije rukovanje ranjivostima zahtjeva poboljšanje analize i prikupljanja podataka u okviru odgovora procesa koji vraća povratnu informaciju aktivnog planiranja. Osnovni zahtjevi koji su ključni za ovu razinu implementacije su detaljna povratna informacija za unaprjeđenje organizacije poslije svakog incidenta. Okvirni troškovi proizašli iz nastalih ranjivosti i dogovorenih kompromisa. Sudionici su u mogućnosti donijeti bolje zaključke, odnosno odluke koje se temelje na različitim povijesnim trendovima.

1.Provesti detaljnu analizu za nastale incidente

2.Skupljanje metrike za svaki incident

Troškovi koji proizlaze na ovoj razini implementacije su tekući troškovi organizacije zbog preopterećenja proizašli iz detaljnih pretraživanja i analiza incidenata. Također, troškovi organizacije koji su proizvedeni zbog preopterećenja skupljanja metrike i revizije incidenta.

"Učvršćivanje" runtime okruženja

Razina 1

implementacije. Prva razina implementacije objašnjava razumijevanje osnovnog dijela operativnog okruženja za aplikacijske i softverske komponente. Jasno razumijevanje operacijskog očekivanja u okviru razvojnog tima. Visoki prioriteti rizika od ublažavanja pozadinskog okruženja infrastrukture na temelju dobrog poznavanja runtime vremenske okosnice. Također je jedan od zahtjeva i softverski operatori s visokom razinom izvedenosti za kritično sigurnosno održavanje infrastrukture.

1.Provoditi specifično operativno okruženje

2.Identificirati i instalirati kritične sigurnosne nadogradnje i zakrpe

Troškovi koji proizlaze iz prve razine implementacije „učvršćivanja“ runtime okruženja su troškovi tekućih projekata koji se odnose na preopterećenje zbog izgradnje i održavanja specifičnog operativnog okruženja i zbog praćenja i instaliranja kritičnih sigurnosnih nadogradnji.

Razina 2

Druga razina implementacije se odnosi na poboljšanje svjesnosti u aplikacijskim operacijama zbog „učvršćivanja“ operativnog okruženja. Zahtjevi koji su potrebni kako bi izgradili ovu razinu implementacije su detaljna potvrda sigurnosnih karakteristika sustava u različitim operacijama. Formalna očekivanja na vremenskoj okosnici za ublažavanje infrastrukturnog rizika. Sudionici trebaju biti konzistentno svjesni trenutnih operativnih stanja softverskih projekata.

1.Formiranje rutinskih zakrpa upravljanja procesa

2.Nadzor temeljnog plana okoline konfiguracijskog stanja

Troškove koji proizlaze i druge razine implementacije se temelje na tekućim organizacijskim preopterećenjima od upravljanja i nadgledanja zakrpa. Također se temelje na kreiranju ili licenci infrastrukture alata za nadgledanje.

Razina 3

Treća razina implementacije komparativno uspoređenje zdravlja i stanja operativnog okruženja u usporedbi s poznatim najboljim praksama. Zahtjevi koji su nam potrebni za ovu razinu implementacije su pojačano operativno okruženje sa slojevitim provjerama sigurnosti. Osnivanje i mjerenje ciljeva za operativno održavanje i performanse. Reducirati mogućnosti uspješnih napada kroz tok vanjskog ovisnog okruženja.

1.Identificirati i uvesti relevantne operativne zaštitne alate

2.Proširiti revizijski program za konfiguraciju okruženja

Troškovi koji se iniciraju u trećoj razini implementacije su troškovi pretraživanja i odabira rješenja operativne zaštite, izgradnja ili licence alata za operativnu zaštitu. Tekuća operativna preopterećenja zbog održavanja zaštitnih alata i troškovi tekućih projekata zbog preopterećenja povezanih infrastrukturnih revizija.

Operativno osposobljavanje

Razina 1

Prva razina implementacije je omogućavanje komunikacije između razvojnog tima i operato za kritične sigurnosno relevantne podatke. Također zahtjevi koje je potrebno ispuniti su ad hoc unapređenje stanja sigurnosti softvera kroz bolje razumijevanje ispravnih operacija. Operatori i korisnici svjesni njihovih uloga u osiguranju sigurnosti uvođenja. Samo poboljšanje komunikacije između tima za razvijanje softvera i korisnika za sigurnosno kritične informacije.

1.Uhvatiti kritične sigurnosne informacije za upravljanje

2.Dokumentirati procedure za tipična aplikacijska upozorenja

Troškove se temelje na tekućim projektima zbog preopterećenja održavanja sigurnosnih informacija i kritičnih operativnih procedura.

Razina 2

Druga razina implementacije je unapređenje očekivanja za kontinuiranu sigurne operacija kroz propisivanje sve detaljnijih procedura. Zahtjevi koji trebaju ispunjavati ovu razinu implementiranosti su detaljne upute za sigurnosno povezane promjene isporuke sa softverskom isporukom. Osvježiti informacijski repozitorij sa sigurnosnim operativnim procedurama za svaku aplikaciju te poravnanje svih operativnih očekivanja među razvojnim sudionicima, operatorima i korisnicima.

1.Kreirati za svaku isporuku promjene potrebne upravljačke procedure

2.Izdržavati formalne operativne sigurnosne upute

Troškovi koji su nastali uslijed primjene druge razine su troškovi tekućih projekata zbog preopterećenja održavanja izmjena upravljanja procedurama i održavanja operativnih sigurnosnih uputa.

Razina 3

Treća razina implementacije govori o upravljanju komunikacijom sigurnosnih informacija i potvrđenih artefakta za cjelovitost. Zahtjevi koji su potrebni pri izradi su široko razumijevanje organizacije i očekivanja za sigurnosno povezanu dokumentaciju, sudionici su u boljoj mogućnosti pronaći kompromisne odluke temeljene na povratnoj informaciji od razvojnog tima i operatora. Operatori i/ili korisnici u mogućnosti su neovisno potvrditi integritet softverske isporuke.

1.Proširenje revizije programa za informacijske operatore

2.Izvedba potpisivanja koda za aplikacijske komponente

Troškovi treće razine implementacije uključuju tekuće projekte zbog preopterećenja revizora operatorskih uputa i identificiranja i potpisivanja modula koda, te zbog upravljanja potpisivanja koda akreditiva.

--Marin Barisic 01:30, 22. siječnja 2016. (CET)

Izvori

http://www.opensamm.org/

http://link.springer.com/article/10.1007%2Fs10270-013-0393-x#/page-1

https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model

Metodologije za razvoj sigurnog softvera

Sadržaj

Uvod

Governance (Upravljanje)

Strategija i metrika

Organizacijska politika i usklađenost s normama

Edukacija i usmjeravanje kadrova

2. Izrada (Construction)

Procjena prijetnji

Sigurnosni zahtjevi

Sigurna arhitektura

Verikifacija (Verification)

Revizija dizajna programskog sustava (Design review)

Revizija koda (Code Review)

Testiranje sigurnosti (Security testing)

Uvođenje (Deployment)

Upravljanje ranjivostima

"Učvršćivanje" runtime okruženja

Operativno osposobljavanje

Izvori

Osobni alati

Imenski prostori

Inačice

Pogledi

Radnje

Traži

Orijentacija

Traka s alatima