Tveganja notranjih oseb: manj priložnosti in boljši odziv

Tveganja notranjih oseb vključujejo namerno zlorabo, napake in dejavnost prek kompromitiranega legitimnega računa. Vpleteni so lahko zaposleni, zunanji sodelavci, dobavitelji in nekdanji delavci s preostalim dostopom. Uporabno izhodišče ni seznam domnevno tveganih ljudi, temveč dostopi in dejanja, ki bi lahko povzročila škodo.

Za tehničnega direktorja je naloga zmanjšati priložnosti za zlorabo, ne da bi oviral legitimno delo, in nato poskrbeti, da je sumljivo dejavnost mogoče preiskati. To zahteva kontrole identitet, pravila ravnanja s podatki, uporabno telemetrijo in proces odziva, ki loči nesrečo od kompromitacije računa ali namernega dejanja. Možne posledice vključujejo goljufije, izgubo intelektualne lastnine, razkritje osebnih podatkov in motnje poslovanja. Nobena od njih ne zahteva, da napadalec izkoristi ranljivost programske opreme, če obstoječa dovoljenja dejanje že omogočajo.

Opredelite poti z velikim vplivom

Začnite z enim pomembnim poslovnim procesom in popišite, kako bi lahko nekdo z legitimnim dostopom povzročil bistveno škodo. Vključite aplikacije, administrativne vmesnike, API-je, končne naprave in zunanje ponudnike. Vaja modeliranja groženj, osredotočena na dostope, lahko pomaga opredeliti poti, ki prečkajo več sistemov.

Vprašajte se, kaj lahko oseba bere, spreminja, izvaža, briše ali odobri, ne le, ali ima račun.

Za vsako pot zapišite skrbnika sredstva, pooblaščene vloge, pričakovani namen, preventivno kontrolo, vir zaznavanja in odzivnika. Prednost določite glede na možen vpliv, enostavnost izvedbe in možnost obnove. Posebno pozornost zasluži občutljivo dejanje, ki ga lahko ena oseba izvede brez neodvisnega preverjanja.

Rezultat je kratek register poti dostopa. Natančno naj opredeli, katero dejanje potrebuje ločevanje dolžnosti, dodatno odobritev ali natančnejše spremljanje.

Odstranite nepotrebna pooblastila, preden dodate nadzor

Načelo najmanjših pravic pomeni, da se dovoljenja ujemajo s trenutnim delom. Začnite z dejanskimi upravičenji, vključno z gnezdenimi skupinami, vlogami v posameznih aplikacijah, delegiranim dostopom, storitvenimi računi, žetoni API in skupnimi poverilnicami. Urejen seznam vlog v imeniku lahko prikrije pretirana dovoljenja v posameznih aplikacijah.

Poslovni skrbniki naj potrdijo, zakaj je posamezno občutljivo upravičenje potrebno. Kjer je praktično, ločite vsakodnevne račune od administrativnih identitet ter stalni administrativni dostop nadomestite z odobrenim, časovno omejenim povišanjem pravic. Uporabite večfaktorsko avtentikacijo, kjer je podprta, po možnosti metode, odporne proti ribarjenju (phishing), da zmanjšate izpostavljenost kompromitaciji poverilnic. Avtentikacija ne prepreči, da bi pooblaščena oseba zlorabila dovoljenja.

Ločevanje dolžnosti mora obstajati v sistemu, ne le v politiki. Oseba, ki spremeni plačilne podatke dobavitelja, ne bi smela odobriti tudi plačila, ki iz tega izhaja. Prepisi v sili potrebujejo zapisan razlog, določen potek in naknadni pregled s strani nekoga, ki je neodvisen od dejanja.

Spremembe dostopov vgradite v kadrovske poteke dela in poteke dela z dobavitelji:

• Prihod: dodelite opredeljeno vlogo, namesto da bi kopirali nakopičena dovoljenja sodelavca.
• Premestitev: odstranite zastarele dostope, ne le dodajte novih odgovornosti.
• Odhod: uskladite onemogočenje računa, prekinitev sej, preklic žetonov, ravnanje z napravami in odvzem dostopa dobaviteljem.
• Začasno delo: povišanemu ali projektnemu dostopu dodelite odgovorno osebo in potek.

Storitvene račune preglejte ločeno. Dokumentirajte njihov namen, odvisnosti, shranjevanje poverilnic in odgovorno osebo. Izogibajte se interaktivni uporabi, kjer ni potrebna. Če skupne poverilnice še ni mogoče odstraniti, zapišite izjemo in nadomestne kontrole; ne domnevajte, da bodo dnevniki zanesljivo identificirali posameznega uporabnika.

Zaščitite podatke in poti iz organizacije

Varstvo podatkov se začne s poznavanjem, katere informacije so pomembne in kam potujejo. Razvrstite občutljive nabore podatkov, opredelite odobrene cilje in določite, kdaj so izvozi ali zunanje deljenje legitimni. Uporabnikom dajte uporabno odobreno pot, sicer lahko kontrole dejavnost potisnejo v neupravljane kanale.

Preprečevanje izgube podatkov (DLP) lahko pri izbranih prenosih opozori, blokira ali zahteva utemeljitev. Politike pred širokim uveljavljanjem preizkusite na reprezentativnih potekih dela. Kjer je relevantno za tveganje, preizkusite povezave za deljenje v oblaku, nalaganje prek brskalnika, odjemalce za sinhronizacijo, izmenljive nosilce in tiskanje. Pokritost se razlikuje glede na platformo in kanal; uspešen test na končni napravi ne dokazuje zaščite za API aplikacije.

Šifriranje v mirovanju in prenosu ščiti določene poti izpostavljenosti, vendar lahko pooblaščeni uporabnik še vedno pridobi nešifrirano besedilo. Šifriranje združite z mejami dostopa, omejitvami izvoza in nadzorovanim deljenjem. Zaščitite tudi varnostne kopije in administracijo obnove: po uničujoči zlorabi je obnova težja, če lahko ista identiteta spreminja proizvodno okolje in briše njegove varnostne kopije.

Zaznavanje naj bo sorazmerno in pojasnljivo

Zbirajte signale, povezane s potmi z velikim vplivom, ne vsega, kar oseba počne. Uporabni dogodki lahko vključujejo nenavadno velike izvoze, novo zunanje deljenje, spremembe pravic, onemogočeno beleženje, ponavljajoče se zavrnjene dostope ali dostop do občutljivih repozitorijev zunaj ustaljenih vzorcev dela.

Revizijske dnevnike aplikacij uporabljajte skupaj z dogodki identitet, končnih naprav in oblaka. Sistem za upravljanje varnostnih informacij in dogodkov (SIEM) lahko te vire poveže; analitika vedenja uporabnikov in entitet (UEBA) lahko pomaga prepoznati odstopanja od izhodišča. Nobeden ne dokazuje namena. Nenavadno dejavnost lahko pojasnijo selitev, odobren odziv na incident ali spremenjena delovna vloga.

Za vsako pravilo zaznavanja določite:

• Tvegano dejanje in zajete sisteme.
• Zahtevana polja dnevnika, kot so akter, časovni žig, objekt, dejanje, izid in cilj.
• Pričakovane legitimne izjeme in način, kako jih odzivniki preverijo.
• Odgovorno osebo za odziv, pot eskalacije in pogoje za nujno zajezitev.
• Kako bo ekipa pravilo preizkusila in izmerila njegovo uporabnost.

Dnevnike zaščitite pred nepooblaščenim spreminjanjem, sinhronizirajte časovne žige in preverite, ali so napake pri zajemu vidne. Opozorila preizkusite z odobreno dejavnostjo v varnem okolju. Manjkajočo telemetrijo in lažno pozitivne zadetke spremljajte kot inženirske napake, ne le kot obremenitev analitikov.

Najprej vzpostavite zaščitne ukrepe za spremljanje

Preden začnete zbirati podatke o dejavnosti zaposlenih, določite pravno podlago, namen, zaščitne ukrepe za zasebnost, kontrole dostopa in hrambo. Vključite ustrezne predstavnike za zasebnost, pravna vprašanja, kadre in delavce; obveznosti posvetovanja so odvisne od jurisdikcije in konteksta.

Kjer se uporablja Splošna uredba o varstvu podatkov (GDPR), njeni členi 5, 6, 13–14 in 32 obravnavajo načela, zakonitost obdelave, preglednost in varnost. Člen 35 zahteva oceno učinka v zvezi z varstvom podatkov, kadar bi obdelava verjetno povzročila veliko tveganje. Varnostni cilji teh zahtev ne odpravijo.

Kot praktično priporočilo dajte prednost ozko omejenim metapodatkom o dogodkih pred posegajočim zbiranjem vsebine, kadar to odgovori na preiskovalno vprašanje. Omejite dostop do primerov, dokumentirajte odločitve o hrambi in osebnih okoliščin ali nesoglasij na delovnem mestu ne obravnavajte kot dokaza kršitve. Samodejne ocene zahtevajo človeško potrditev.

Ljudem pomagajte, da napake prijavijo zgodaj

Zagotovite očitno pot za prijavo nenamernega deljenja, izgubljenih naprav, sumljivih zahtev in nepričakovane dejavnosti v računu. Pojasnite, kaj prijaviti: sistem, približen čas, zadevne informacije, prejemnike in že izvedena dejanja. Zaposlenim ne bi smelo biti treba razvrstiti incidenta, preden prosijo za pomoč.

Usposabljanje naj bo prilagojeno delu. Finančne ekipe potrebujejo scenarije za preverjanje sprememb plačilnih podatkov; razvijalci potrebujejo primere za repozitorije in ravnanje s skrivnostmi; osebje podpore potrebuje smernice za izvoze strank in poskuse lažnega predstavljanja. Vključite zunanje sodelavce in privilegirane administratorje.

Na hitre prijave se odzovite konstruktivno. Prijavitelju povejte, ali naj preneha uporabljati napravo, ohrani sporočilo ali se vzdrži stika s prejemnikom, dokler ga ne usmeri odzivna ekipa. Jasna navodila preprečijo, da bi dobronamerno čiščenje uničilo dokaze ali razširilo izpostavljenost.

Odzivajte se na dejstva, ne na oznake

Opozorilo je izhodišče za preiskavo, ne dokaz kršitve. Ugotovite kontekst in zaščitite zaupnost vseh vpletenih. Navidezno veljavno dejanje v računu je lahko posledica napake, avtomatizacije, ukradene seje ali namerne zlorabe; potrebe po zajezitvi se lahko prekrivajo, posledice za delovno razmerje pa se razlikujejo.

Uporaben priročnik za odziv naj zajema pet odločitev:

1. Razvrščanje: potrdite dogodek, prizadeta sredstva, občutljivost, pooblastilo in ali škoda še traja. Preverite odobrene spremembe in se prek zaupanja vrednega kanala obrnite na skrbnika procesa.
2. Ohranitev: kjer je primerno, ohranite relevantne dnevnike, dogodke identitet, zapise o deljenju in izvirne datoteke. Zapišite čas zbiranja, vir, preiskovalca in ravnanje. Omejite dostop do gradiva primera.
3. Zajezitev: izberite sorazmerne ukrepe, kot so preklic sej, omejitev izvozov, onemogočenje deljenja ali odvzem povišanih pravic. Pred onemogočenjem računa upoštevajte odvisnosti storitev, ne da bi zavlekli nujno zaščito.
4. Usklajevanje: glede na dejstva vključite varnost, skrbnika sistema, zasebnost, pravno službo in kadrovsko službo. Ukrepi v delovnem razmerju in prijave organom pregona zahtevajo ustrezno pooblastilo, ne samodejnega praga opozoril.
5. Obnova: obnovite odobrene dostope in konfiguracije, zamenjajte prizadete poverilnice, preverite celovitost podatkov in spremljajte morebitne ponovitve.

Določite, kdo lahko odobri nujno zajezitev, in nadomestni kontakt, če je vpleten privilegiran administrator ali običajni odločevalec.

Dolžnosti obveščanja ocenite ločeno. V skladu s členoma 33 in 34 GDPR upravljavci brez nepotrebnega odlašanja in, kadar je izvedljivo, v 72 urah po seznanitvi ocenijo uradno obvestilo nadzornemu organu, razen če ni verjetno, da bi kršitev ogrozila pravice in svoboščine posameznikov. Obdelovalci upravljavce obvestijo brez nepotrebnega odlašanja. Veliko tveganje lahko zahteva sporočilo prizadetim posameznikom, ob upoštevanju izjem iz člena 34. Zapišite utemeljitev, zakaj obvestilo ni bilo poslano, in preverite druge veljavne pogodbene ali zakonske dolžnosti.

Primer: nenavaden izvoz strank

Ponazoritvene predpostavke: aplikacija za podporo vsebuje kontaktne podatke strank; nadzorniki lahko za odobrene primere izvozijo omejeno število zapisov; ločena integracijska identiteta izvaja načrtovano poročanje.

Opozorilo poroča, da je nadzornik izvozil bistveno več zapisov, kot ustreza njegovi običajni delovni obremenitvi. Analitik preveri obseg izvoza, cilj, dogodke identitete in sklic na odobren primer. Nov kontekst prijave poveča zaskrbljenost, ne dokazuje pa, kdo je dejanje izvedel.

Odzivna ekipa ohrani dnevnike aplikacije in identitet, prekliče sumljivo sejo in uporabniku začasno odvzame pravico izvoza. Preden spremeni širše dostope, preveri, ali načrtovana integracija ni prizadeta. Prek zaupanja vrednega kontakta nadzornik potrdi, da izvoza ni zahteval.

Delovna hipoteza postane kompromitacija računa. Preiskovalci preučijo izpostavljenost poverilnic in sej, kjer je mogoče, opredelijo prejemnike ali cilje ter ocenijo dolžnosti obveščanja o kršitvi. Obnova vključuje zavarovanje računa in preverjanje dovoljenj.

Pregled kontrol pokaže, da rutinsko delo podpore ni zahtevalo širokih pravic izvoza. Korektivni ukrep je ožja vloga, odobritev za večje izvoze in preizkušeno opozorilo. Dokazila vključujejo zapise o konfiguraciji, nadzorovan test in odobritev pregledovalca, ne pa trditve, da bo vsak prihodnji izvoz preprečen.

Hranite dokazila, ki kažejo, da kontrole delujejo

Po primeru ali vaji zajemite dejstva, odziv, vpliv in izboljšave. Preučite, ali so k temu prispevala pretirana dovoljenja, manjkajoče odobritve, nejasna navodila ali nepopolna telemetrija. Vsakemu korektivnemu ukrepu dodelite odgovorno osebo, rok in metodo preverjanja.

Uporabna dokazila za zagotovilo vključujejo preglede upravičenj z zapisi o odvzemih, zgodovino povišanj pravic, teste odhodov, teste pravil zaznavanja, preverjanja pokritosti dnevnikov in vaje, ki dokazujejo pot eskalacije. Merite izide kontrol, kot so odstranjeni potečeni dostopi in opozorila z zadostnim kontekstom, namesto da bi šteli le opravljena usposabljanja.

Secani povezuje tveganja, izvedbo kontrol in dokazila v upravljanem kontekstu. Za eno pot dostopa lahko ekipe modelirajo relevantne sisteme, priložijo izvoze pregledov in zapise testov, dodelijo naloge za odpravo vrzeli in ohranijo človeške odločitve pri pregledu. Dokumentacija o dovoljenjih in dostopu do API opisuje vlogo OSCAL API, ki omogoča le validacijo, kot konkreten primer, kako poverilnicam dati zmogljivost, omejeno na nameravano nalogo. Izvoze pregledov dostopov, ugotovitve spremljanja in odobrene odločitve o odzivu prenesite v ta povezani zapis o kontrolah.

Začnite s preizkusom ene poti dostopa z velikim vplivom in poti eskalacije, če je ta zlorabljena. Potrdite, da so nepotrebna pooblastila odstranjena, da je pomemben dogodek viden in da lahko pooblaščen odzivnik ukrepa z dovolj dokazi in konteksta.