Unutarnji rizik: smanjite prilike za zlouporabu i poboljšajte odgovor

Unutarnji rizik uključuje namjernu zlouporabu, pogreške i aktivnosti putem kompromitiranog legitimnog računa. Mogu biti uključeni zaposlenici, vanjski suradnici, dobavljači i bivši djelatnici s preostalim pristupom. Korisna polazna točka nije popis navodno rizičnih osoba, nego pristup i radnje koji bi mogli prouzročiti štetu.

Za tehničkog direktora zadatak je smanjiti prilike za zlouporabu uz očuvanje legitimnog rada, a zatim omogućiti istragu sumnjivih aktivnosti. To zahtijeva kontrole identiteta, pravila postupanja s podacima, korisnu telemetriju i proces odgovora koji razlikuje nezgodu od kompromitacije računa ili namjerne radnje. Moguće posljedice uključuju prijevaru, gubitak intelektualnog vlasništva, izlaganje osobnih podataka i operativni poremećaj. Ni za jednu od njih napadač ne mora iskoristiti softversku ranjivost ako postojeće ovlasti već omogućuju tu radnju.

Utvrdite putove velikog učinka

Počnite s jednim važnim poslovnim procesom i mapirajte kako bi netko mogao prouzročiti bitnu štetu koristeći legitiman pristup. Uključite aplikacije, administrativna sučelja, API-je, krajnje uređaje i vanjske pružatelje. Vježba modeliranja prijetnji usmjerena na pristup može pomoći u utvrđivanju putova koji prolaze kroz više sustava.

Pitajte što osoba može čitati, mijenjati, izvoziti, brisati ili odobravati, a ne samo ima li račun.

Za svaki put evidentirajte vlasnika imovine, ovlaštene uloge, očekivanu svrhu, preventivnu kontrolu, izvor otkrivanja i osobu koja reagira. Odredite prioritete prema mogućem učinku, lakoći izvršenja i mogućnosti oporavka. Osjetljiva radnja koju jedna osoba može izvršiti bez neovisnih provjera zaslužuje posebnu pažnju.

Rezultat je kratak registar putova pristupa. Trebao bi točno utvrditi koja radnja zahtijeva razdvajanje dužnosti, dodatno odobrenje ili pomniji nadzor.

Uklonite nepotrebne ovlasti prije dodavanja nadzora

Načelo najmanjih ovlasti znači usklađivanje ovlasti s trenutačnim poslom. Počnite od stvarnih prava, uključujući ugniježđene grupe, uloge specifične za aplikacije, delegirani pristup, servisne račune, API tokene i zajedničke vjerodajnice. Uredan popis uloga u imeniku može prikriti prekomjerne ovlasti unutar pojedinih aplikacija.

Neka poslovni vlasnici potvrde zašto je svako osjetljivo pravo potrebno. Ondje gdje je izvedivo, odvojite svakodnevne račune od administrativnih identiteta i zamijenite stalni administrativni pristup odobrenim, vremenski ograničenim podizanjem ovlasti. Koristite višefaktorsku autentifikaciju, po mogućnosti metode otporne na krađu identiteta (phishing) ondje gdje su podržane, kako biste smanjili izloženost kompromitaciji vjerodajnica. Autentifikacija ne sprječava ovlaštenu osobu da zloupotrijebi ovlasti.

Razdvajanje dužnosti mora postojati u sustavu, a ne samo u politici. Osoba koja mijenja podatke za plaćanje dobavljaču ne bi smjela i odobriti plaćanje koje iz toga proizlazi. Hitna zaobilaženja trebaju evidentirani razlog, definirani istek i naknadni pregled koji provodi osoba neovisna o radnji.

Ugradite promjene pristupa u kadrovske tijekove rada i tijekove rada s dobavljačima:

• Dolazak: dodijelite definiranu ulogu umjesto kopiranja nagomilanih ovlasti kolege.
• Promjena uloge: uklonite zastarjeli pristup, a ne samo dodajte nove odgovornosti.
• Odlazak: koordinirajte onemogućavanje računa, prekid sesija, opoziv tokena, postupanje s uređajima i uklanjanje pristupa dobavljača.
• Privremeni rad: dodijelite odgovornu osobu i istek za podignute ovlasti ili pristup vezan uz projekt.

Servisne račune pregledavajte zasebno. Dokumentirajte njihovu svrhu, ovisnosti, pohranu vjerodajnica i odgovornu osobu. Izbjegavajte interaktivnu upotrebu ako nije potrebna. Ako se zajednička vjerodajnica još ne može ukloniti, evidentirajte iznimku i kompenzacijske kontrole; ne pretpostavljajte da će zapisi pouzdano identificirati pojedinog korisnika.

Zaštitite podatke i put kojim izlaze

Zaštita podataka počinje znanjem koje su informacije važne i kamo se kreću. Klasificirajte osjetljive skupove podataka, utvrdite odobrena odredišta i definirajte kada su izvozi ili vanjsko dijeljenje legitimni. Dajte korisnicima izvediv odobreni put, inače kontrole mogu potisnuti aktivnosti u neupravljane kanale.

Sprječavanje gubitka podataka (DLP) može upozoriti, blokirati ili zahtijevati obrazloženje za odabrane prijenose. Isprobajte politike na reprezentativnim tijekovima rada prije široke primjene. Ondje gdje je to relevantno za rizik, testirajte poveznice za dijeljenje u oblaku, prijenose putem preglednika, klijente za sinkronizaciju, prijenosne medije i ispis. Obuhvat se razlikuje ovisno o platformi i kanalu; uspješan test na krajnjem uređaju ne dokazuje zaštitu za API aplikacije.

Enkripcija u mirovanju i u prijenosu štiti određene putove izloženosti, ali ovlašteni korisnik i dalje može dohvatiti nešifrirani sadržaj. Kombinirajte enkripciju s granicama pristupa, ograničenjima izvoza i kontroliranim dijeljenjem. Zaštitite i sigurnosne kopije i administraciju oporavka: od destruktivne zlouporabe teže se oporaviti kada isti identitet može mijenjati produkciju i brisati njezine sigurnosne kopije.

Neka otkrivanje bude razmjerno i objašnjivo

Prikupljajte signale vezane uz putove velikog učinka, a ne sve što osoba radi. Korisni događaji mogu uključivati neuobičajeno velike izvoze, novo vanjsko dijeljenje, promjene ovlasti, isključeno bilježenje, ponovljeno odbijeni pristup ili pristup osjetljivim repozitorijima izvan uobičajenih obrazaca rada.

Koristite zapise za reviziju aplikacija zajedno s događajima iz sustava identiteta, krajnjih uređaja i oblaka. Sustav za upravljanje sigurnosnim informacijama i događajima (SIEM) može povezati te izvore; analitika ponašanja korisnika i entiteta (UEBA) može pomoći u utvrđivanju odstupanja od osnovnog obrasca. Ni jedno ni drugo ne dokazuje namjeru. Migracija, odobreni odgovor na incident ili promijenjena radna uloga mogu objasniti neuobičajenu aktivnost.

Za svako pravilo otkrivanja navedite:

• Rizičnu radnju i obuhvaćene sustave.
• Potrebna polja zapisa, kao što su akter, vremenska oznaka, objekt, radnja, ishod i odredište.
• Očekivane legitimne iznimke i način na koji ih osobe koje reagiraju provjeravaju.
• Osobu odgovornu za odgovor, put eskalacije i uvjete za hitno ograničavanje.
• Kako će tim testirati pravilo i mjeriti njegovu korisnost.

Zaštitite zapise od neovlaštenih izmjena, sinkronizirajte vremenske oznake i provjerite jesu li neuspjesi unosa vidljivi. Testirajte upozorenja odobrenim aktivnostima u sigurnom okruženju. Nedostajuću telemetriju i lažno pozitivne rezultate pratite kao inženjerske nedostatke, a ne samo kao opterećenje analitičara.

Najprije uspostavite zaštitne mjere za nadzor

Prije prikupljanja podataka o aktivnostima zaposlenika utvrdite pravnu osnovu, svrhu, zaštitne mjere za privatnost, kontrole pristupa i čuvanje. Uključite odgovarajuće predstavnike za privatnost, pravna pitanja, kadrovsku službu i predstavnike radnika; obveze savjetovanja ovise o nadležnosti i kontekstu.

Ako se primjenjuje GDPR (Opća uredba o zaštiti podataka), njegovi članci 5., 6., 13. – 14. i 32. odnose se na načela, zakonitost obrade, transparentnost i sigurnost. Članak 35. zahtijeva procjenu učinka na zaštitu podataka kada je vjerojatno da će obrada prouzročiti visok rizik. Sigurnosni ciljevi ne ukidaju te zahtjeve.

Kao praktičnu preporuku, dajte prednost usko ograničenim metapodacima o događajima pred nametljivim prikupljanjem sadržaja kada oni odgovaraju na istražno pitanje. Ograničite pristup predmetima, dokumentirajte odluke o čuvanju i ne smatrajte osobne okolnosti ili neslaganja na radnom mjestu dokazom nedoličnog ponašanja. Automatizirane ocjene zahtijevaju ljudsku provjeru.

Pomozite ljudima da rano prijave pogreške

Osigurajte očit put za prijavu slučajnog dijeljenja, izgubljenih uređaja, sumnjivih zahtjeva i neočekivanih aktivnosti na računu. Objasnite što treba prijaviti: sustav, približno vrijeme, uključene informacije, primatelje i već poduzete radnje. Zaposlenici ne bi trebali morati klasificirati incident prije nego što zatraže pomoć.

Prilagodite osposobljavanje poslu. Financijskim timovima trebaju scenariji provjere promjena podataka za plaćanje; razvojnim inženjerima primjeri postupanja s repozitorijima i tajnama; osoblju podrške smjernice o izvozima podataka o kupcima i pokušajima lažnog predstavljanja. Uključite vanjske suradnike i povlaštene administratore.

Na brze prijave reagirajte konstruktivno. Recite osobi koja prijavljuje treba li prestati koristiti uređaj, sačuvati poruku ili izbjegavati kontakt s primateljem dok joj tim za odgovor ne da upute. Jasne upute sprječavaju da dobronamjerno „čišćenje“ uništi dokaze ili proširi izloženost.

Reagirajte na činjenice, a ne na etikete

Upozorenje je trag za istragu, a ne dokaz nedoličnog ponašanja. Utvrdite kontekst i zaštitite povjerljivost svih uključenih. Naizgled valjana radnja na računu može odražavati pogrešku, automatizaciju, ukradenu sesiju ili namjernu zlouporabu; potrebe za ograničavanjem mogu se preklapati, dok se radnopravne implikacije razlikuju.

Upotrebljiv priručnik za odgovor trebao bi obuhvatiti pet odluka:

1. Trijaža: potvrdite događaj, pogođenu imovinu, osjetljivost, ovlaštenje i nastavlja li se šteta. Provjerite odobrene promjene i kontaktirajte vlasnika procesa putem pouzdanog kanala.
2. Očuvanje: ondje gdje je primjereno, sačuvajte relevantne zapise, događaje identiteta, zapise o dijeljenju i izvorne datoteke. Evidentirajte vrijeme prikupljanja, izvor, istražitelja i postupanje. Ograničite pristup materijalima predmeta.
3. Ograničavanje: odaberite razmjerne mjere poput opoziva sesija, ograničavanja izvoza, isključivanja dijeljenja ili uklanjanja podignutih ovlasti. Prije onemogućavanja računa razmotrite ovisnosti usluga, ali bez odgađanja hitne zaštite.
4. Koordinacija: ovisno o činjenicama, uključite sigurnosni tim, vlasnika sustava, stručnjake za privatnost, pravnu službu i kadrovsku službu. Radnopravne mjere i prijave tijelima kaznenog progona zahtijevaju odgovarajuće ovlasti, a ne automatizirani prag upozorenja.
5. Oporavak: vratite odobreni pristup i konfiguracije, promijenite pogođene vjerodajnice, provjerite cjelovitost podataka i pratite ponavljanje.

Definirajte tko može odobriti hitno ograničavanje i zamjenski kontakt ako je umiješan povlašteni administrator ili uobičajeni donositelj odluka.

Obveze obavješćivanja procijenite zasebno. Prema člancima 33. i 34. GDPR-a voditelji obrade procjenjuju obavješćivanje nadzornog tijela bez nepotrebnog odgađanja i, ako je izvedivo, u roku od 72 sata od saznanja, osim ako nije vjerojatno da povreda prouzroči rizik za prava i slobode pojedinaca. Izvršitelji obrade obavješćuju voditelje obrade bez nepotrebnog odgađanja. Visok rizik može zahtijevati obavješćivanje pogođenih pojedinaca, uz iznimke iz članka 34. Evidentirajte obrazloženje odluke o neobavješćivanju i provjerite druge primjenjive ugovorne ili zakonske dužnosti.

Primjer iz prakse: neuobičajen izvoz podataka o kupcima

Ilustrativne pretpostavke: aplikacija za podršku sadržava kontaktne podatke kupaca; nadzornici smiju izvoziti ograničen broj zapisa za odobrene predmete; zaseban integracijski identitet izrađuje zakazana izvješća.

Upozorenje javlja da je nadzornik izvezao znatno više zapisa nego što odgovara njegovu uobičajenom opsegu posla. Analitičar provjerava opseg izvoza, odredište, događaje identiteta i referencu odobrenog predmeta. Novi kontekst prijave povećava zabrinutost, ali ne utvrđuje tko je djelovao.

Tim za odgovor čuva zapise aplikacije i identiteta, opoziva sumnjivu sesiju i privremeno uklanja korisnikovo pravo izvoza. Provjerava da zakazana integracija nije pogođena prije promjene šireg pristupa. Putem pouzdanog kontakta nadzornik potvrđuje da nije zatražio izvoz.

Radna hipoteza postaje kompromitacija računa. Istražitelji ispituju izloženost vjerodajnica i sesija, gdje je moguće utvrđuju primatelje ili odredišta i procjenjuju obveze obavješćivanja o povredi. Oporavak uključuje osiguravanje računa i provjeru ovlasti.

Pregled kontrola utvrđuje da rutinski rad podrške nije zahtijevao široka prava izvoza. Korektivna radnja je uža uloga, odobrenje za veće izvoze i testirano upozorenje. Dokazi uključuju zapise o konfiguraciji, kontrolirani test i odobrenje recenzenta, a ne tvrdnju da će svaki budući izvoz biti spriječen.

Čuvajte dokaze koji pokazuju da kontrole funkcioniraju

Nakon predmeta ili vježbe zabilježite činjenice, odgovor, učinak i poboljšanja. Ispitajte jesu li tome pridonijele prekomjerne ovlasti, nedostajuća odobrenja, nejasne upute ili nepotpuna telemetrija. Svakoj korektivnoj radnji dodijelite odgovornu osobu, rok i metodu provjere.

Korisni dokazi za jamstvo uključuju preglede prava sa zapisima o uklanjanju, povijest podizanja ovlasti, testove procesa odlaska, testove pravila otkrivanja, provjere obuhvata zapisa i vježbe koje pokazuju put eskalacije. Mjerite ishode kontrola, primjerice uklonjen istekli pristup i upozorenja s dovoljno konteksta, umjesto da brojite samo dovršena osposobljavanja.

Secani povezuje rizike, provedbu kontrola i dokaze u upravljanom kontekstu. Za jedan put pristupa timovi mogu modelirati relevantne sustave, priložiti izvoze pregleda i zapise o testovima, dodijeliti zadatke za otklanjanje nedostataka i sačuvati odluke iz ljudskog pregleda. Dokumentacija o ovlastima i pristupu API-ju opisuje ulogu OSCAL API-ja namijenjenu isključivo validaciji, konkretan primjer dodjeljivanja vjerodajnicama mogućnosti ograničene na njihovu namijenjenu zadaću. Unesite izvoze pregleda pristupa, nalaze nadzora i odobrene odluke o odgovoru u tu povezanu evidenciju kontrola.

Počnite testiranjem jednog puta pristupa velikog učinka i puta eskalacije u slučaju njegove zlouporabe. Potvrdite da su nepotrebne ovlasti uklonjene, da je bitan događaj vidljiv i da ovlaštena osoba koja reagira može djelovati s dovoljno dokaza i konteksta.