Upravljanje proširenjima preglednika za NIS2, DORA i GDPR
Maria, CISO brzorastuće fintech tvrtke, smatrala je da prethodna procjena prema DORA-i napreduje dobro. Njezin je tim pripremio registar IKT trećih strana, ključne SaaS ugovore, zapise o dubinskoj analizi dobavljača, odluke o prihvaćanju rizika i paket izvješća za upravljačko tijelo.
Zatim je revizor postavio pitanje za koje nitko nije bio pripremljen.
“Možete li nam pokazati svoj proces upravljanja proširenjima preglednika?”
Pitanje je proizašlo iz pregleda krajnjeg uređaja s financijskim analitičarom. Tijekom dijeljenja zaslona revizor je u pregledniku analitičara uočio proširenje treće strane za produktivnost. Izgledalo je bezazleno, ali brza provjera pokazala je da je razvojni programer tri mjeseca ranije pretrpio kompromitaciju lanca opskrbe. Kompromitirano proširenje korišteno je za eksfiltraciju tokena sesije za velike SaaS platforme.
Fintech tvrtka imala je stroge politike protiv neovlaštenog softvera. Imala je EDR, MFA, CASB, SaaS dnevničke zapise i ISMS usklađen s ISO/IEC 27001. No nitko nije tretirao preglednik kao upravljanu softversku platformu. Nitko nije popisao proširenja. Nitko nije odobrio njihova dopuštenja. Nitko nije provjerio treba li razvojne programere proširenja tretirati kao dobavljače. Nitko nije mapirao aktivnosti proširenja na dokaze za DORA, NIS2 ili GDPR.
Jedno proširenje preglednika pretvorilo je krajnji uređaj koji je izgledao usklađeno u moguća stražnja vrata prema financijskim sustavima, podacima klijenata i reguliranim tijekovima rada.
To je problem upravljanja proširenjima preglednika u 2026. Preglednik više nije samo prozor prema internetu. To je mjesto na kojem se zaposlenici autentificiraju, odobravaju plaćanja, pristupaju CRM zapisima, obrađuju osobne podatke, upravljaju infrastrukturom oblaka i komuniciraju s ključnim SaaS platformama. Proširenja više nisu kozmetički dodaci. Ona su kod trećih strana koji se izvršava unutar najosjetljivijeg sloja suvremenog rada.
Za CISO-ove, rukovoditelje usklađenosti, DPO-ove i vlasnike IKT rizika neupravljana proširenja nalaze se na sjecištu sigurnosti krajnjih uređaja, IT-a u sjeni, rizika dobavljača, upravljanja promjenama, upravljanja ranjivostima i odgovornosti za privatnost. ISO/IEC 27001:2022 organizacijama daje strukturu za upravljanje tim rizikom. NIS2, DORA i GDPR stvaraju regulatorni pritisak da se to i dokaže.
Proširenja preglednika su softver, dobavljači i izvršitelji obrade
Većina organizacija već je naučila upravljati prijenosnim računalima, mobilnim uređajima, poslužiteljima, SaaS aplikacijama, infrastrukturom oblaka i povlaštenim računima. Proširenja preglednika često ostaju između tih programa.
Sigurnosni timovi vide ih kao postavku preglednika. Nabava ih ne vidi jer se ne potpisuje ugovor. Pravni poslovi ih ne vide jer nije otvoren zahtjev za uvođenje dobavljača. Timovi za privatnost ih ne vide jer proširenje instalira korisnik, a ne uvodi se kao službena aplikacija. Ipak, proširenje može zatražiti dopuštenje za čitanje i mijenjanje podataka na svim web-mjestima, pristup sadržaju međuspremnika, prikupljanje metapodataka stranice, upravljanje preuzimanjima, umetanje skripti ili komunikaciju s vanjskim pozadinskim sustavom.
To znači da proširenje preglednika istodobno može biti sve sljedeće:
| Perspektiva upravljanja | Zašto je važno | Tipičan način neuspjeha |
|---|---|---|
| Softver | Mijenja ponašanje krajnjeg uređaja i može izvršavati kod u korisničkim sesijama | Korisnici instaliraju proširenja izvan odobrenih tijekova rada za softver |
| Dobavljač | Razvojni programer kontrolira ažuriranja, infrastrukturu i podršku | Ne provodi se dubinska analiza dobavljača |
| Usluga u oblaku | Mnoga proširenja povezuju se s hostiranim API-jima ili SaaS platformama | Pozadinski sustavi proširenja ne pregledavaju se kao usluge u oblaku |
| Rizik izvršitelja obrade | Proširenja mogu vidjeti podatke klijenata, zaposlenika ili financijske podatke | Timovi za privatnost ne procjenjuju pristup podacima ni pravnu osnovu |
| Izloženost ranjivostima | Proširenja mogu biti kompromitirana, napuštena ili zlonamjerna | Ne provjeravaju se zakrpe, reputacija ni poznata kompromitacija |
| Izvor incidenta | Aktivnost proširenja može stvoriti neovlašteni pristup ili eksfiltraciju podataka | Nedostaju dnevnički zapisi, što otežava istragu i obavješćivanje |
[ZB] Zenith Blueprint: Revizorov plan u 30 koraka sažima ključni problem u svojim smjernicama ISO/IEC 27002:2022 za kontrolu 8.19. Upozorava da “čak i osoblje s najboljim namjerama može instalirati alate kako bi ‘brže obavilo posao’ — proširenje preglednika, biblioteku koda, aplikaciju za prijenos datoteka — ne shvaćajući da je upravo uvelo stražnja vrata, nezakrpanu ovisnost ili vektor eksfiltracije podataka.”
Tu rečenicu treba tretirati kao izjavu o riziku na razini upravnog odbora. Zaposlenici koji instaliraju rizična proširenja najčešće ne pokušavaju zaobići sigurnost. Pokušavaju povećati produktivnost. Neuspjeh upravljanja nastaje kada organizacija ne osigura siguran proces zahtjeva, odobravanja, uvođenja i praćenja.
Zašto NIS2, DORA i GDPR ovu slijepu točku čine hitnom
Rizik proširenja preglednika postoji godinama, ali se regulatorni kontekst promijenio. U 2026. od organizacija se očekuje da pokažu ne samo da kontrole postoje, nego i da su temeljene na riziku, integrirane, praćene i potkrijepljene dokazima.
NIS2 podiže očekivanja za kibernetičku higijenu i sigurnost lanca opskrbe. DORA zahtijeva da financijski subjekti upravljaju IKT rizikom kroz interne ovisnosti i ovisnosti o trećim stranama. GDPR zahtijeva da voditelji i izvršitelji obrade dokažu sigurnost obrade, odgovornost i ugrađenu zaštitu podataka. Neupravljana proširenja mogu narušiti sva tri okvira.
| Regulativa | Relevantnost proširenja preglednika | Dokazi koje očekuju regulatori i revizori |
|---|---|---|
| NIS2 Article 21 | Proširenja utječu na kibernetičku higijenu, postupanje s ranjivostima, kontrolu pristupa, sigurnost softvera i rizik lanca opskrbe | Popis proširenja, popis dopuštenih, zapisi procjene rizika, dnevnički zapisi blokiranih instalacija, dokazi o postupanju s incidentima |
| NIS2 Article 23 | Kompromitirano proširenje može stvoriti značajan incident koji zahtijeva rano upozorenje i obavješćivanje | Dnevnički zapisi detekcije, zapisi trijaže, procjena utjecaja, dokazi o odluci o obavješćivanju |
| DORA Article 5 | Upravljačka tijela ostaju odgovorna za upravljanje IKT rizicima | Politike, odluke o sklonosti riziku, izvješćivanje, odobrenja iznimki |
| DORA Article 6 | Proširenja mogu utjecati na okvir za upravljanje IKT rizicima | Identifikacija imovine, zaštitne kontrole, praćenje, testiranje otpornosti, zapisi o korektivnim radnjama |
| DORA Article 28 | Razvojni programeri proširenja i povezane usluge mogu biti IKT ovisnosti o trećim stranama | Dubinska analiza dobavljača, klasifikacija rizika, zapisi u registru, ugovorna procjena gdje je primjenjivo |
| GDPR Article 5(2) | Organizacije moraju dokazati odgovornost za obradu osobnih podataka | Dokumentirane procjene, odluke o odobrenju, vlasništvo, učestalost pregleda |
| GDPR Article 25 | Ugrađena i zadana zaštita podataka primjenjuje se na odabir alata | Minimizacija dopuštenja, pregled privatnosti, konfiguracija prema načelu zadane zabrane |
| GDPR Article 32 | Sigurnost obrade zahtijeva odgovarajuće tehničke i organizacijske mjere | Kontrole krajnjih uređaja, ograničenja pristupa, zapisivanje događaja, praćenje, upravljanje ranjivostima |
| GDPR Article 33 | Spremnost za prijavu povrede ovisi o pravodobnom otkrivanju i dokazima | Dnevnički zapisi incidenata, analiza utjecaja na osobne podatke, dokazi o rokovima obavješćivanja |
Pouka je jednostavna. Proširenje preglednika nije premalo da bi bilo važno. Ako može zahvatiti regulirane podatke, autentificirane sesije, financijske tijekove rada ili ključne SaaS usluge, mora biti pod upravljanjem.
Koristite ISO/IEC 27001:2022 kao operativni model
ISO/IEC 27001:2022 učinkovit je za upravljanje proširenjima preglednika jer ne zahtijeva zaseban silos usklađenosti. Omogućuje organizacijama da postojeće ISMS procese prošire na sloj preglednika.
Praktičan kontrolni model temelji se na osam kontrola iz Priloga A standarda ISO/IEC 27001:2022:
| Kontrola ISO/IEC 27001:2022 | Ispravan naziv kontrole | Primjena na proširenja preglednika |
|---|---|---|
| 5.10 | Prihvatljiva uporaba informacija i druge povezane imovine | Definirati što korisnici smiju instalirati, koristiti, zahtijevati i pohranjivati u preglednicima |
| 5.19 | Informacijska sigurnost u odnosima s dobavljačima | Tretirati razvojne programere proširenja i povezane usluge kao rizike dobavljača gdje je relevantno |
| 5.23 | Informacijska sigurnost pri korištenju usluga u oblaku | Pregledavati proširenja koja se povezuju s vanjskim SaaS API-jima ili pozadinskim sustavima u oblaku |
| 8.1 | Korisnički krajnji uređaji | Upravljati konfiguracijom preglednika kao dijelom zaštite krajnjih uređaja |
| 8.8 | Upravljanje tehničkim ranjivostima | Pratiti ranjiva, napuštena, kompromitirana ili visokorizična proširenja |
| 8.15 | Zapisivanje događaja | Bilježiti instalaciju, uklanjanje, blokirane pokušaje, promjene politike i administratorske radnje |
| 8.16 | Aktivnosti praćenja | Upozoravati na anomalnu aktivnost proširenja i kršenja politike |
| 8.19 | Instalacija softvera na operativne sustave | Zahtijevati odobrenje prije instalacije proširenja na radne sustave |
[ZC] Zenith Controls: Vodič za međusobnu usklađenost posebno je koristan jer objašnjava kako se kontrole ISO/IEC 27001 revidiraju i kako podupiru dokaze za više okvira. Za kontrolu 8.19, Zenith Controls: Vodič za međusobnu usklađenost objašnjava da će revizori “pratiti tijek rada: od zahtjeva preko testiranja do odobrenja i implementacije.” Upravo tako treba oblikovati upravljanje proširenjima.
Ako revizor pronađe proširenje koje nije na popisu dopuštenih, nije dokumentirano u zapisima promjena i nije procijenjeno s aspekta rizika, problem više nije samo postavka preglednika. To postaje dokaz slabe kontrole instalacije softvera, slabog upravljanja krajnjim uređajima i mogućeg neuspjeha u upravljanju rizikom dobavljača.
Korak 1, otkrijte okruženje proširenja
Prvi neuspjeh kontrole u Marijinoj fintech tvrtki bila je vidljivost. Njezin tim nije znao koja su proširenja instalirana, tko ih je instalirao, koja dopuštenja traže ni povezuju li se s vanjskim uslugama.
Otkrivanje treba obuhvatiti sve upravljane preglednike, profile, korisnike, uređaje i operativne sustave. Treba identificirati naziv proširenja, jedinstveni ID, verziju, izdavača, izvor instalacije, skup dopuštenja, datum instalacije, status ažuriranja, broj korisnika, poslovnog vlasnika te je li proširenje prisilno instalirano, instalirano od strane korisnika, instalirano izvan službene trgovine ili blokirano.
Kontrola 8.1, Korisnički krajnji uređaji, temeljna je kontrola. Smjernice Zenith Blueprint: Revizorov plan u 30 koraka za kontrolu 8.1 navode da korisnički krajnji uređaji “moraju biti ojačani, praćeni i kontrolirani.” Taj zahtjev prirodno uključuje preglednik jer je preglednik sada primarno sučelje korisničkog krajnjeg uređaja za SaaS i rad u oblaku.
Kontrola 5.23 također se primjenjuje kada se proširenja povezuju s uslugama u oblaku. Zenith Blueprint: Revizorov plan u 30 koraka ovaj kontrolni zahtjev postavlja kao odgovor na IT u sjeni, gdje korisnici usvajaju neodobrene usluge bez upravljanja. Proširenje preglednika koje šalje sadržaj nepoznatom hostiranom pozadinskom sustavu predstavlja događaj usvajanja usluge u oblaku, čak i ako ga nitko u nabavi nije odobrio.
Zreo rezultat otkrivanja trebao bi klasificirati svako proširenje u jedno od pet stanja:
| Stanje proširenja | Značenje | Obvezna radnja |
|---|---|---|
| Odobreno | Pregledano, opravdano i dopušteno za definirane korisnike | Pratiti i periodično pregledavati |
| Uvjetno | Dopušteno uz ograničenja, kao što su određene grupe, web-mjesta ili dopuštenja | Provesti uvjete i češće pregledavati |
| Čeka pregled | Otkriveno ili zatraženo, ali još nije procijenjeno | Blokirati ili staviti u karantenu do odobrenja |
| Blokirano | Poznato kao rizično, nepotrebno, neusklađeno ili zabranjeno | Spriječiti instalaciju i ukloniti postojeće instance |
| Iznimka | Privremeno dopušteno zbog poslovne potrebe i prihvaćenog rizika | Evidentirati vlasnika, datum isteka, kompenzacijske kontrole i odobravatelja |
Otkrivanje ne smije biti jednokratan projekt. Proširenja se često ažuriraju, izdavači mijenjaju vlasništvo, dopuštenja se proširuju, a trgovine uklanjaju zlonamjerne pakete tek nakon što su ih korisnici već instalirali. Popis mora postati kontinuiran ili barem dovoljno redovit da podupire upravljanje ranjivostima i revizijske dokaze.
Korak 2, jasno definirajte prihvatljivu uporabu
Kada su proširenja vidljiva, očekivanja od korisnika moraju biti jasna. Mnoge organizacije već imaju formulacije politika koje mogu poduprijeti upravljanje proširenjima, ali ih treba izričito primijeniti na preglednik.
[P-EPM] Politika zaštite krajnjih uređaja i zaštite od zlonamjernog softvera – SME navodi da korisnici “ne smiju instalirati neovlašteni softver ili dodatke koji mogu uvesti rizik.” Ta jedna rečenica sigurnosnim timovima daje snažnu osnovu politike da proširenja preglednika tretiraju kao kontrolirani softver.
[P03-AUP] P03 Politika prihvatljive uporabe, koja se također navodi kao korporativna Politika prihvatljive uporabe, zabranjuje “Neodobrene alate: instaliranje ili korištenje neovlaštenog softvera, hardvera, usluga u oblaku ili uređaja”. To je temelj usmjeren prema korisnicima. Njime se upravljanje proširenjima preglednika pretvara iz tehničke preferencije u provediv zahtjev ponašanja i usklađenosti.
Snažna politika za proširenja preglednika treba odgovoriti na šest praktičnih pitanja:
| Pitanje politike | Odgovor upravljanja |
|---|---|
| Smiju li korisnici slobodno instalirati proširenja? | Ne, proširenja zahtijevaju odobrenje osim ako nisu unaprijed odobrena prema ulozi ili grupi |
| Smatraju li se proširenja preglednika softverom? | Da, to je softver instaliran na operativne sustave |
| Smatraju li se pozadinski sustavi proširenja uslugama u oblaku? | Da, kada obrađuju, prenose, pohranjuju ili obogaćuju podatke organizacije |
| Tko odobrava proširenja? | Sigurnost, IT, privatnost i poslovni vlasnici odobravaju na temelju rizika |
| Što se događa s neodobrenim proširenjima? | Blokiraju se, uklanjaju ili stavljaju u karantenu do pregleda |
| Kako se postupa s iznimkama? | Iznimke zahtijevaju dokumentirano prihvaćanje rizika, datum isteka i kompenzacijske kontrole |
Ovdje nije riječ o zabrani svakog korisnog proširenja. Riječ je o prelasku s implicitnog povjerenja na izričito odobrenje. Neka proširenja mogu biti sigurna, potrebna i korisna za produktivnost. Druga mogu biti nepotrebna, imati preširoka dopuštenja, biti napuštena ili zlonamjerna. Program upravljanja mora ih razlikovati.
Korak 3, provedite zadanu zabranu uz popis dopuštenih po iznimci
Kontrola 8.19, Instalacija softvera na operativne sustave, kontrola je koja politiku pretvara u operativnu provedbu. Proširenja preglednika ne treba tretirati drukčije od drugog softvera samo zato što ih korisnici instaliraju putem trgovine preglednika.
Zenith Blueprint: Revizorov plan u 30 koraka izravan je u tom pogledu: “nijedan softver ne instalira se ako nije opravdan, ovlašten i osiguran.” Za proširenja preglednika to znači korištenje alata za upravljanje poslovnim preglednicima, upravljanje krajnjim uređajima ili konfiguraciju uređaja radi provedbe pravila instalacije.
Najdokaziviji model je zadana zabrana uz popis dopuštenih po iznimci:
- Blokirati sva proširenja prema zadanim postavkama za upravljane preglednike.
- Prisilno instalirati samo nužna, odobrena korporativna proširenja.
- Održavati popis dopuštenih proširenja prema korisničkoj grupi, odjelu ili ulozi.
- Blokirati proširenja instalirana izvan službene trgovine i nepouzdane izvore instalacije.
- Spriječiti korisnike da zaobiđu politike prebacivanjem profila ili korištenjem neupravljanih preglednika.
- Ukloniti već instalirana proširenja koja nisu odobrena.
- Pregledati dopuštenja proširenja i rizik izdavača prije odobrenja.
- Bilježiti dopuštena, blokirana, uklonjena i izmijenjena proširenja.
Neke organizacije počinju blažim modelom zbog operativne složenosti. Mogu prvo napraviti popis, blokirati poznato loša proširenja, a zatim postupno uvesti popise dopuštenih za visokorizične grupe kao što su financije, inženjering, privilegirani administratori, pravni poslovi, HR i korisnička podrška. To je prihvatljivo ako postoji dokumentiran plan. Ono što nije dokazivo jest trajna tolerancija nepoznatog rizika proširenja.
Korak 4, procjenjujte rizik proširenja kao rizik dobavljača i softvera
Pregled rizika proširenja preglednika treba biti dovoljno jednostavan za poslovno usvajanje, ali dovoljno snažan da izdrži reviziju. Pregled treba objediniti rizik softvera, rizik dobavljača, rizik oblaka, zaštitu podataka i upravljanje ranjivostima.
[P-TP] Politika sigurnosti trećih strana i dobavljača zahtijeva da “svi novi dobavljači moraju proći dokumentiranu sigurnosnu procjenu prije izvršenja ugovora.” Neće svaki razvojni programer proširenja zahtijevati puni korporativni proces uvođenja dobavljača, ali načelo rizika dobavljača i dalje se primjenjuje. Ako razvojni programer može slati ažuriranja koda u preglednike zaposlenika ili obrađivati podatke organizacije putem pozadinske usluge, organizacija ima ovisnost o trećoj strani.
[P-ASR] Politika zahtjeva za sigurnost aplikacija – SME potvrđuje isti zahtjev iz softverske perspektive: “svaki alat treće strane, dodatak ili vanjska biblioteka koda koji se koriste u aplikaciji moraju biti evidentirani i pregledani jednom godišnje u pogledu sigurnosnog utjecaja i statusa zakrpa.”
Koristite sljedeći model rizika za standardizaciju odluka:
| Čimbenik rizika | Nizak rizik | Srednji rizik | Visok rizik |
|---|---|---|---|
| Dopuštenja | Nema pristup podacima stranice | Pristup aktivnoj kartici ili ograničenim web-mjestima | Pristup za čitanje i pisanje na svim web-mjestima |
| Izdavač | Provjeren izdavač sa snažnom poviješću | Poznata tvrtka s politikom privatnosti | Nepoznata fizička osoba, nejasno vlasništvo, nema politike privatnosti |
| Pristup podacima | Radi lokalno bez osjetljivih podataka | Vidi ograničene poslovne podatke | Pristupa osobnim podacima, financijskim podacima, tajnim vrijednostima ili sadržaju sesije |
| Povezivost | Nema vanjski pozadinski sustav | Povezuje se s poznatom uslugom | Povezuje se s nepoznatim ili netransparentnim pozadinskim sustavom treće strane |
| Model ažuriranja | Službena trgovina, redovita ažuriranja | Rijetka ažuriranja, ograničen zapis promjena | Instalirano izvan službene trgovine, napušteno ili nejasan izvor ažuriranja |
| Poslovna potreba | Potrebno za odobreni tijek rada | Korisno, ali zamjenjivo | Samo praktičnost uz široka dopuštenja |
| Povijest ranjivosti | Nema nepovoljnih nalaza | Prethodni problemi otklonjeni | Poznata kompromitacija, zlonamjerno ponašanje ili neriješena ranjivost |
| Profil privatnosti | Jasna obavijest o privatnosti i ograničeno prikupljanje | Široka politika, ali prihvatljive kontrole | Nema jasne politike ili prekomjerno prikupljanje |
Visokorizično proširenje ne smije se odobriti osim ako postoji kritična poslovna potreba, dokumentirane kompenzacijske kontrole i prihvaćanje rizika od strane višeg rukovodstva. Primjeri kompenzacijskih kontrola uključuju ograničavanje uporabe na sigurnosno očvrsnuti profil preglednika, ograničavanje na određene URL-ove, blokiranje unosa podataka u osjetljive aplikacije dok je proširenje aktivno, korištenje DLP praćenja ili zahtijevanje ugovora s dobavljačem i dodatka o privatnosti.
Korak 5, integrirajte pregled privatnosti i GDPR-a
Upravljanje proširenjima preglednika često ne uspijeva jer je pregled privatnosti odvojen od alata za krajnje uređaje. Ipak, mnoga proširenja mogu vidjeti osobne podatke prikazane u SaaS aplikacijama, HR sustavima, zahtjevima korisničke podrške, CRM zapisima, e-pošti, analitičkim platformama i alatima za suradnju.
Prema GDPR Article 5(2), organizacija mora dokazati odgovornost. Prema Article 25, mora primijeniti ugrađenu i zadanu zaštitu podataka. Prema Article 32, mora primijeniti odgovarajuće tehničke i organizacijske mjere za sigurnost obrade. Ako proširenje eksfiltrira osobne podatke, događaj može postati povreda osobnih podataka prema Article 4(12), što pokreće procjenu i moguće obveze obavješćivanja prema Article 33.
Pregled proširenja usmjeren na privatnost treba postaviti sljedeća pitanja:
| Područje pregleda prema GDPR-u | Pitanje za pregled proširenja | Dokazi koje treba zadržati |
|---|---|---|
| Kategorije podataka | Može li proširenje pristupiti osobnim podacima, posebnim kategorijama podataka ili financijskim podacima? | Procjena pristupa podacima |
| Ograničenje svrhe | Je li proširenje potrebno za definiranu poslovnu svrhu? | Poslovno opravdanje |
| Minimizacija podataka | Jesu li tražena dopuštenja ograničena na potreban minimum? | Pregled dopuštenja |
| Odnos s izvršiteljem obrade | Obrađuje li pružatelj proširenja podatke u ime organizacije? | Procjena dobavljača i privatnosti |
| Međunarodni prijenosi | Napuštaju li podaci jurisdikciju ili odobrenu regiju hostinga? | Procjena prijenosa |
| Zadržavanje | Pohranjuje li pružatelj podatke, dnevničke zapise, upite, snimke zaslona ili metapodatke? | Obavijest o privatnosti i pregled zadržavanja |
| Sigurnost | Jesu li šifriranje, kontrole pristupa i prakse upravljanja ranjivostima odgovarajući? | Dubinska analiza sigurnosti |
| Odgovor na povredu | Može li pružatelj obavijestiti organizaciju o incidentima? | Ugovorni ili dokumentirani dokazi o odgovoru |
Ne zahtijeva svako proširenje punu DPIA. Međutim, proširenja sa širokim pristupom stranicama, AI obradom, snimanjem zaslona, pristupom e-pošti, pristupom CRM-u, pristupom HR podacima, podacima korisničke podrške ili reguliranim financijskim podacima trebaju pokrenuti strukturiranu procjenu privatnosti.
Korak 6, bilježite i pratite za reviziju i odgovor na incidente
Program upravljanja proširenjima bez dnevničkih zapisa nije prikladan za reviziju. On također slabi odgovor na incidente jer organizacija ne može utvrditi kada je proširenje instalirano, tko ga je koristio, koja je verzija bila prisutna, kada su se dopuštenja promijenila ili je li došlo do blokiranog pokušaja instalacije.
[P-LM] Politika zapisivanja događaja i praćenja – SME identificira dnevničke zapise za “instalacije softvera” kao ključni zahtjev upravljanja. Instalacija proširenja preglednika događaj je instalacije softvera i treba je u skladu s time zabilježiti.
Dnevnički zapisi trebaju najmanje uključivati:
| Događaj u dnevničkom zapisu | Zašto je važan |
|---|---|
| Proširenje instalirano | Potvrđuje uvođenje i podupire dokaze o promjeni |
| Proširenje blokirano | Pokazuje djelovanje preventivne kontrole |
| Proširenje uklonjeno | Potvrđuje otklanjanje nedostataka |
| Proširenje ažurirano | Podupire pregled ranjivosti i promjena |
| Dopuštenje promijenjeno | Otkriva povećanje rizika nakon odobrenja |
| Politika promijenjena | Pokazuje administrativnu kontrolu i odgovornost |
| Pokušaj instalacije izvan službene trgovine | Ukazuje na pokušaj zaobilaženja ili rizik od zlonamjernog softvera |
| Izvor trgovine promijenjen | Otkriva nepouzdan put instalacije |
| Otkriveno visokorizično proširenje | Pokreće trijažu i uklanjanje |
| Korisnička iznimka odobrena | Podupire dokaze o prihvaćanju rizika |
Ti dnevnički zapisi trebaju se uključiti u procese praćenja prema kontrolama 8.15 i 8.16. Ovisno o riziku, mogu se također slati u SIEM, platformu krajnjih uređaja ili repozitorij dokaza usklađenosti. Upozorenja treba konfigurirati za blokirana visokorizična proširenja, nagle poraste zahtjeva za proširenjima, promjene dopuštenja odobrenih proširenja, pokušaje instalacije iz neslužbenih izvora i pokušaje instalacije od strane privilegiranih korisnika.
Praćenje je također prednost za NIS2 i DORA. Prijavljivanje incidenata prema NIS2 Article 23 ovisi o ranom otkrivanju i procjeni utjecaja. DORA zahtijeva robusno postupanje s IKT incidentima i dokaze otpornosti. Procjena povrede prema GDPR-u ovisi o saznanju što se dogodilo, kada i koji su podaci mogli biti zahvaćeni.
Što revizor želi vidjeti
Revizor se rijetko zadovoljava izjavom poput “blokiramo rizična proširenja”. Želi dokaze upravljanja. Dokazi moraju povezivati politiku, procjenu rizika, tehničku provedbu, praćenje i odgovornost uprave.
| Revizijsko pitanje | Snažan odgovor | Artefakt dokaza |
|---|---|---|
| Jesu li proširenja preglednika u opsegu? | Da, tretiraju se kao softver na korisničkim krajnjim uređajima | Opseg ISMS-a, registar imovine, standard krajnjih uređaja |
| Je li korisnicima zabranjena instalacija neodobrenih proširenja? | Da, pravilo definiraju politike prihvatljive uporabe i krajnjih uređaja | Politika zaštite krajnjih uređaja i zaštite od zlonamjernog softvera – SME, P03 Politika prihvatljive uporabe |
| Postoji li odobreni popis proširenja? | Da, odobrena proširenja dokumentirana su prema poslovnom vlasniku i korisničkoj grupi | Izvoz popisa dopuštenih, registar odobrenja |
| Procjenjuju li se nova proširenja s aspekta rizika? | Da, zahtjevi pokreću provjere softvera, dobavljača, ranjivosti i privatnosti | Zapis procjene rizika |
| Tretiraju li se razvojni programeri proširenja kao dobavljači gdje je relevantno? | Da, visokorizični pružatelji prolaze dubinsku analizu dobavljača | Procjena dobavljača |
| Pregledavaju li se proširenja povezana s oblakom? | Da, vanjski pozadinski sustavi procjenjuju se u okviru upravljanja uslugama u oblaku | Pregled usluge u oblaku |
| Provodi li se instalacija tehnički? | Da, zadana zabrana i grupni popisi dopuštenih provode se u upravljanju preglednicima | Izvoz konfiguracije |
| Bilježe li se promjene? | Da, instalacije, blokiranja, uklanjanja, ažuriranja i administratorske promjene bilježe se u dnevničkim zapisima | SIEM ili dnevnički zapisi administratorske konzole |
| Kontroliraju li se iznimke? | Da, iznimke zahtijevaju vlasnika, datum isteka, odobravatelja i kompenzacijske kontrole | Registar iznimki |
| Ponavljaju li se pregledi? | Da, proširenja se periodično pregledavaju i nakon značajnih promjena | Raspored pregleda i dokazi |
Ovdje Zenith Controls: Vodič za međusobnu usklađenost postaje vrijedan. Pomaže organizacijama pokazati kako jedna kontrolna aktivnost podupire više očekivanja usklađenosti. Jedan tijek rada za odobravanje proširenja preglednika može poduprijeti ISO/IEC 27001 kontrolu 8.19, kibernetičku higijenu NIS2, upravljanje IKT rizicima prema DORA i odgovornost prema GDPR-u ako se dokazi zadržavaju i jasno mapiraju.
Mapiranje, ISO/IEC 27001:2022 prema NIS2, DORA i GDPR
Praktično mapiranje pomaže CISO-ima objasniti zašto upravljanje proširenjima preglednika nije uska tehnička kontrola. To je kontrola usklađenosti sa širokom regulatornom vrijednošću.
| Kontrola ISO/IEC 27001:2022 | Usklađenje s NIS2 | Usklađenje s DORA | Usklađenje s GDPR | Dokazi za proširenja preglednika |
|---|---|---|---|---|
| 5.10 Prihvatljiva uporaba informacija i druge povezane imovine | Article 21 kibernetička higijena i korisničke prakse | Article 5 očekivanja upravljanja | Article 5(2) odgovornost | Pravila prihvatljive uporabe, svijest korisnika, potvrde upoznatosti s politikom |
| 5.19 Informacijska sigurnost u odnosima s dobavljačima | Article 21 sigurnost lanca opskrbe | Article 28 upravljanje IKT rizicima trećih strana | Articles 28 and 32 gdje se primjenjuje obrada | Pregled dobavljača, procjena pružatelja, analiza ugovora |
| 5.23 Informacijska sigurnost pri korištenju usluga u oblaku | Article 21 IKT i mrežna sigurnost | Articles 6 and 28 IKT rizik i ovisnosti o trećim stranama | Articles 25 and 32 ugrađena zaštita privatnosti i sigurnost | Pregled pozadinskog sustava u oblaku, odobrenje SaaS integracije |
| 8.1 Korisnički krajnji uređaji | Article 21 sigurnost krajnjih uređaja i kontrola pristupa | Article 6 okvir za upravljanje IKT rizicima | Article 32 sigurnost obrade | Konfiguracija preglednika, upravljani profili, popis krajnjih uređaja |
| 8.8 Upravljanje tehničkim ranjivostima | Article 21 postupanje s ranjivostima | Article 6 zaštita i prevencija | Article 32 tehničke mjere | Praćenje ranjivih proširenja, zapisi o otklanjanju nedostataka |
| 8.15 Zapisivanje događaja | Article 23 dokazi o incidentima | Postupanje s IKT incidentima i dokazi otpornosti | Articles 5(2), 32, and 33 odgovornost i dokazi o povredi | Dnevnički zapisi instalacija, blokirani pokušaji, promjene politike |
| 8.16 Aktivnosti praćenja | Article 21 detekcija i Article 23 prijavljivanje | IKT praćenje i otkrivanje incidenata | Articles 32 and 33 otkrivanje povrede | Upozorenja, SIEM događaji, izvješća o anomalijama |
| 8.19 Instalacija softvera na operativne sustave | Article 21 sigurna konfiguracija i kontrola softvera | Očekivanja kontrole IKT promjena, uključujući COBIT BAI06 Managed IT Changes kao revizijsku perspektivu | Articles 25 and 32 kontrolirano okruženje obrade | Zahtjev, odobrenje, testiranje, uvođenje, dokazi popisa dopuštenih |
Mapiranje na DORA zaslužuje posebnu pozornost. Neki revizori i procjenitelji koristit će terminologiju nalik COBIT-u pri pregledu upravljanja IKT promjenama. COBIT BAI06 uobičajeno se razumije kao Managed IT Changes. Ako su proširenja preglednika softver i njihova instalacija mijenja korisničko računalno okruženje, tada instalacija proširenja pripada istoj logici upravljanja promjenama. Zenith Controls: Vodič za međusobnu usklađenost podupire ovu revizijsku perspektivu pokazujući kako se dokazi kontrola ISO/IEC 27001 mogu ponovno koristiti za očekivanja usklađenosti u više okvira.
Plan implementacije upravljanja proširenjima preglednika u 90 dana
Organizacije ne moraju sve riješiti u jednom tjednu. Praktičan program može se izgraditi u fazama, osobito ako je poslovnim poremećajima potrebno pažljivo upravljati.
| Vremenski okvir | Cilj | Radnje | Isporučevine |
|---|---|---|---|
| Dani 1 do 15 | Uspostaviti opseg i vlasništvo | Dodijeliti IT, sigurnost, privatnost, nabavu i poslovne vlasnike, potvrditi upravljane preglednike i korisničke grupe | Popis vlasnika upravljanja, opseg preglednika, početna izjava o riziku |
| Dani 16 do 30 | Otkriti trenutačno stanje | Popisati instalirana proširenja, dopuštenja, izdavače, verzije, korisnike i izvore instalacije | Popis proširenja, visokorizični nalazi, početni sažetak za rukovodstvo |
| Dani 31 do 45 | Definirati politiku i pravila odlučivanja | Ažurirati postupke prihvatljive uporabe, krajnjih uređaja, oblaka i dobavljača kako bi uključivali proširenja | Ažuriranja politika, kriteriji odobravanja, postupak iznimki |
| Dani 46 do 60 | Izgraditi tijek rada za procjenu rizika | Izraditi obrazac zahtjeva, model bodovanja, pitanja privatnosti, trijažu dobavljača i zapise odobrenja | Tijek rada za zahtjev za proširenje, matrica rizika, predlošci dokaza |
| Dani 61 do 75 | Provesti tehničke kontrole | Konfigurirati zadanu zabranu ili fazne popise dopuštenih, blokirati instalacije izvan službene trgovine, ukloniti poznata rizična proširenja | Konfiguracija upravljanja preglednikom, popis dopuštenih, popis blokiranih |
| Dani 76 do 90 | Pratiti i dokazivati | Slati dnevničke zapise u alate za praćenje, izraditi upozorenja, testirati revizijske dokaze, izvijestiti upravu | Nadzorna ploča zapisivanja događaja, pravila upozorenja, revizijski paket, izvješće upravi |
Za visokorizične organizacije, osobito financijske subjekte pod DORA-om ili ključne i važne subjekte pod NIS2, prva faza provedbe treba dati prioritet korisnicima s pristupom kritičnim sustavima, reguliranim podacima, privilegiranim administrativnim konzolama, financijskim platformama, alatima korisničke podrške i razvojnim okruženjima.
Poruka za upravni odbor
Upravljanje proširenjima preglednika ne treba predstaviti izvršnim rukovoditeljima kao projekt sigurnosnog očvršćivanja preglednika. Treba ga predstaviti kao kontrolu nad neprovjerenim kodom trećih strana u reguliranim tijekovima rada.
Upravni odbor i upravljačko tijelo moraju razumjeti četiri točke:
- Preglednik je sada temeljna poslovna platforma.
- Proširenja mogu pristupati osjetljivim SaaS podacima i autentificiranim sesijama.
- Neupravljana proširenja stvaraju rizik dobavljača, privatnosti, incidenata i otpornosti.
- ISO/IEC 27001:2022 pruža dokaziv kontrolni model koji podupire dokaze za NIS2, DORA i GDPR.
Takav okvir raspravu odmiče od tehničke preferencije prema operativnoj otpornosti. Također podupire financiranje upravljanja poslovnim preglednicima, integracije krajnjih uređaja, praćenja, pregleda privatnosti, trijaže dobavljača i automatizacije revizijskih dokaza.
Od slijepe točke do strateške kontrole
Marijin revizijski problem nije uzrokovao jedan analitičar instaliranjem jednog alata za produktivnost. Uzrokovala ga je neupravljana kategorija rizika. Organizacija je izgradila snažan program usklađenosti oko vidljive imovine, vidljivih dobavljača, vidljivih SaaS platformi i vidljivih krajnjih uređaja, ali sloj proširenja preglednika ostao je nevidljiv.
Taj je jaz sada prevažan da bi se ignorirao.
Rješenje nije komplicirano, ali mora biti namjerno. Tretirajte preglednik kao dio krajnjeg uređaja. Tretirajte proširenja kao softver. Tretirajte razvojne programere proširenja i pozadinske sustave kao dobavljače gdje je relevantno. Tretirajte dopuštenja kao pristup podacima. Tretirajte instalaciju kao promjenu. Tretirajte dnevničke zapise kao dokaze usklađenosti.
Dokaziv program započinje s četiri radnje:
- Otkriti svako proširenje u upravljanim preglednicima i na krajnjim uređajima.
- Definirati prihvatljivu uporabu i pravila zadane zabrane koristeći Politika zaštite krajnjih uređaja i zaštite od zlonamjernog softvera – SME, P03 Politika prihvatljive uporabe i korporativnu Politiku prihvatljive uporabe.
- Procijeniti zahtjeve za proširenja prema kriterijima dobavljača, oblaka, ranjivosti i privatnosti iz Politike sigurnosti trećih strana i dobavljača i Politike zahtjeva za sigurnost aplikacija – SME.
- Provesti i pratiti aktivnost instalacije koristeći upravljanje preglednicima, zapisivanje događaja i prakse dokazivanja usklađene s Politikom zapisivanja događaja i praćenja – SME.
Za CISO-ove koji se pripremaju za revizije prema NIS2, DORA, GDPR ili ISO/IEC 27001:2022, upravljanje proširenjima preglednika poboljšanje je kontrole visoke vrijednosti jer zatvara stvarni put napada i istodobno stvara ponovno upotrebljive dokaze u više okvira.
Kako biste ubrzali posao, preuzmite Zenith Blueprint: Revizorov plan u 30 koraka i mapirajte svoje dokaze uz Zenith Controls: Vodič za međusobnu usklađenost. Ako želite pretvoriti kaos proširenja preglednika u program upravljanja spreman za reviziju, dogovorite Clarysec procjenu ili demo i započnite s praktičnim popisom, mapom rizika i 90-dnevnim planom kontrola.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
