Kako razširiti skladnost, ne da bi pomnožili papirologijo

Prvi program skladnosti morda teče prek enega ustanovitelja in ene preglednice. Rast prinese nove storitve, lokacije, stranke, dobavitelje in obveznosti. Pritisk nastane, ker se razmerja množijo hitreje, kot jih ekipa zmore usklajevati: ena storitev identitete podpira več izdelkov, en dobavitelj vpliva na več poslovnih procesov, več zahtev po zagotovilih pa je odvisnih od istih dokazil.

Z vidika izvršnega direktorja je cilj ohraniti zanesljive odločitve, ko se ta razmerja širijo. Dodajanje dokumentov je preprosto. Težje je vedeti, katero storitev dokument zajema, kdo ga je preveril in ali osnovna kontrola še deluje.

Razširljiv program loči ponovno uporabljivo delo od lokalne izvedbe, porazdeli operativno odgovornost in strokovno pozornost prihrani za odločitve, ki potrebujejo strokovno znanje. Avtomatizacija pomaga, ko ti temelji obstajajo. Sicer nejasne odgovornosti le prenese v hitrejši potek dela.

Ozko grlo prepoznajte, preden kupite rešitev

Ni univerzalnega števila zaposlenih, pri katerem preglednice postanejo neprimerne. Razmeroma majhno podjetje z reguliranimi strankami in več storitvami ima lahko več dela z usklajevanjem kot večje podjetje, ki deluje v eni stabilni meji.

Namesto tega bodite pozorni na operativne znake:

• Različne ekipe znova in znova zahtevajo ista dokazila.
• Vprašalniki strank vsak teden prekinjajo varnostni inženiring.
• Nihče ne zna opredeliti, katere storitve dokončana kontrola dejansko zajema.
• Priprava na presojo je odvisna od ene osebe, ki odločitve rekonstruira iz e-pošte.
• Nove storitve se zaženejo, preden so dokumentirane odgovornosti, dobavitelji in izjeme.
• Rutinska preverjanja izpodrinejo ocene tveganj, odpravljanje ali pripravo na incidente.

Ti znaki ločujejo delovno obremenitev od zmogljivosti. Ekipa morda potrebuje dodatno strokovno znanje za oceno zapletene arhitekture. Morda pa potrebuje boljši potek dela, ker sposobni ljudje porabijo čas za iskanje zapisov. Zaposlovanje, usposabljanje, avtomatizacija in zunanja podpora rešujejo različne probleme; vodstvo naj omejitev diagnosticira, preden financira odziv.

Prosite za kratek vzorec nedavnega dela na skladnosti. Zapišite čas, porabljen za pridobivanje konteksta, zbiranje gradiva, pregledovanje in odločanje. Rezultat naj opredeli največje breme, ki se mu je mogoče izogniti, ne le skupnega števila ur.

Razširite register obveznosti, ne vsakega projekta skladnosti

Rast ustvari več vrst zahtev. Zakonov, pogodb s strankami, prostovoljnih standardov in notranjih zavez ne gre obravnavati kot zamenljivih. Zahteva kupca po poročilu o zagotovilih se razlikuje od zakonske dolžnosti poročanja o incidentih.

Vzdržujte register obveznosti, ki za vsako zahtevo navaja poslovno dejavnost, ki jo sproži, jurisdikcijo, odgovorno osebo, relevanten obseg, datum pregleda in vir razlage. Ob vstopu na trg ali uvedbi storitve naročite osredotočen pregled uporabnosti, namesto da bi samodejno dodali vsak znan okvir.

ISO 27001 se na primer nanaša na sistem upravljanja informacijske varnosti z opredeljenim obsegom. Njegov obseg naj odraža ocenjevane storitve in odvisnosti. Certifikat za eno mejo ne dokazuje izvedbe povsod v podjetju, poročilo o atestaciji SOC 2 pa ni certifikacija.

Podobno so obveznosti po Splošni uredbi o varstvu podatkov (GDPR) odvisne od obdelave in organizacijskih vlog. Uporabnost Direktive NIS 2 je odvisna od sektorja, velikosti, storitve, pravil o vključitvi in nacionalnega prenosa. Prodaja tehnologije finančni instituciji dobavitelja ne postavi samodejno v enak položaj kot subjekt, ki ga neposredno zajema Uredba o digitalni operativni odpornosti (DORA), čeprav lahko sledijo pogodbene zahteve.

Tudi uvajanje UI zasluži preverjanje uporabnosti glede na primer uporabe in vlogo organizacije, pri čemer si pomagajte s Komisijinim pregledom Akta o umetni inteligenci. Popis odobrenih in neodobrenih uporab UI je boljše izhodišče kot zgolj splošna politika.

Rezultat za vodstvo je utemeljena odločitev o uporabnosti, pri kateri so odprta vprašanja dodeljena usposobljenim svetovalcem. Te analize ne nadomesti niti orodje niti obstoječi certifikat.

Ločite skupno delo od lokalne izvedbe

Opredelite kontrole, ki so skupne celotni organizaciji, kot so osrednje upravljanje identitet, upravljanje politik, uvajanje zaposlenih ali sprejem dobaviteljev. Nato zapišite, kje se izvedba razlikuje.

Skupna politika ima lahko na dveh lokacijah različna dokazila. Osrednje kontrole identitet lahko zajemajo večino aplikacij, medtem ko prevzeto podjetje še vedno uporablja ločen imenik. Odobrena izjema ene ekipe ne sme tiho postati izjema za vse.

Uporabite tri povezane ravni:

Obsege opredelite okoli smiselnih poslovnih meja: upravljane storitve, izdelka, lokacije ali poslovnega procesa. Vsak potrebuje odgovorno osebo, ki lahko potrdi izvedbo in eskalira spremembe. Pomembne so tudi tehnične meje: obseg poslovne storitve naj opredeli podporne sisteme in ponudnike, od katerih je odvisna.

Preslikava kontrol tako postane ponovno uporabljiva, ne da bi implicirala enakovrednost. Ena kontrola upravljanja dostopov lahko podpira več zahtev, vendar vsaka preslikava potrebuje utemeljitev, veljavno različico in obseg. Nekatere zahteve potrebujejo tudi dodatne postopke ali dokazila. Cilj je izogniti se podvojeni izvedbi, ne izbrisati razlik med obveznostmi. Pristop iz preslikave kontrol med okviri je uporaben, ko se skupno delo začne razcepljati v ločene projekte za posamezne okvire.

Dokazilom določite namen

Osrednja mapa zmanjša iskanje, ne pojasni pa, kaj datoteka dokazuje. Dokazila potrebujejo kontekst, preden jih je mogoče varno ponovno uporabiti.

Za vsak pomemben element zapišite njegov vir, datum zbiranja, relevantno obdobje, zajete sisteme ali storitve, odgovorno osebo, pregledovalca ter podporno kontrolo ali zahtevo. Vključite sklep: ustrezno, nepopolno, zastarelo ali potrebno nadaljnjih ukrepov. Utemeljitev naj ostane pripeta k zapisu.

Ločite tri vprašanja:

1. Zasnova: Ali je postopek zmožen izpolniti nameravano zahtevo?
2. Izvedba: Ali je uveden v celotnem navedenem obsegu?
3. Delovanje: Ali je deloval v relevantnem obdobju?

Odobrena politika dostopa podpira zasnovo. Konfiguracija sistema podpira izvedbo. Opravljeni pregledi in razrešene ugotovitve pomagajo dokazati delovanje. Ponovna uporaba same politike ne more odgovoriti na vsa tri vprašanja.

Intervale pregledovanja dokazil določite glede na tveganje, hitrost sprememb in potrebe po zagotovilih. To je praktično priporočilo, ne splošen zakonski razpored. Stabilna politika in hitro spreminjajoča se konfiguracija privilegiranih dostopov ne bi smeli samodejno imeti enakega intervala osveževanja.

Zahteve za dokazila naj navedejo populacijo, obdobje, pričakovani vir, merila sprejemljivosti in prejemnika. „Predložite dokazila o pregledu dostopov“ vabi k dodatnim vprašanjem. „Predložite pregled, ki zajema administratorje proizvodnega okolja za navedeno četrtletje, vključno z odobritvijo pregledovalca in razrešitvijo ugotovljenih odvzemov“ pa odgovorni osebi da nalogo, ki jo lahko opravi.

Zaščitite tudi skladišče. Dokazila lahko vsebujejo osebne podatke, varnostno arhitekturo ali občutljive poslovne informacije. Omejite dostop in delite le tisto, kar prejemnik potrebuje. Za zagotovila strankam je lahko primernejši pregledan paket odgovorov kot razdeljevanje surovih notranjih zapisov.

Avtomatizirajte ponovljivo delo in zaščitite presojo

Najboljši kandidati za avtomatizacijo imajo stabilen vhod, jasno pravilo in opredeljeno pot za izjeme. Začnite s ponavljajočimi se opomniki, predlogami zahtev za dokazila, usmerjanjem k odgovornim osebam in združevanjem stanja. Kjer obstajajo ustrezne tehnične zmogljivosti, lahko zbiranje iz izvornih sistemov in preverjanje konfiguracij zmanjšata ročno zbiranje.

Uspešnega zbiranja ne zamenjujte z učinkovito kontrolo. Izvoz lahko izpusti hčerinsko družbo, izključi storitvene račune ali zajema napačno obdobje. Nekdo mora preveriti pokritost in odločiti, kaj izjeme pomenijo.

Ko izvedba dozori, lahko tehnične ekipe izbrana preverjanja vgradijo v cevovode za uvajanje ali infrastrukturne predloge. To zahteva vzdrževane teste, nadzorovane spremembe in odziv, ko preverjanje ne uspe. Uspešno opravljen tehnični test ne izpolni vsake organizacijske ali pravne zahteve.

Pripravo osnutkov in razvrščanje s pomočjo UI naj vodi enaka disciplina: omejen dostop, vidni viri in izrecna človeška odobritev pomembnih sklepov. Samodejen predlog je osnutek, ne sprejetje tveganja.

Gradite zmogljivosti, ne da bi varnost postala vsem druga služba

Redki strokovnjaki so najdragocenejši pri zahtevnih ocenah, odločitvah o zasnovi in odločitvah o tveganjih. Jasne zahteve za dokazila in odgovornosti zmanjšajo čas, ki ga porabijo za rekonstrukcijo konteksta ali lovljenje rutinskih zapisov.

Naloge porazdelite ljudem, ki proces že izvajajo. Kadrovska služba lahko zagotovi zapise o prihodih in odhodih; IT lahko pokaže upravljanje računov; nabava lahko vzdržuje podatke o sprejemu dobaviteljev; skrbniki storitev lahko potrdijo lokalno izvedbo. Varnostna ekipa določa merila, podpira odgovorne osebe in pregleduje izjeme, namesto da bi vsako nalogo opravila sama.

Usposabljanje naj bo konkretno. Odgovorna oseba za dokazila mora razumeti, kaj predložiti in kdaj eskalirati. Skrbnik storitve mora prepoznati spremembe, ki vplivajo na obseg. Nobeden od njiju ne potrebuje postati strokovnjak za vse okvire.

Zunanja podpora lahko zapolni resnične vrzeli v zmogljivostih: omejeno pravno razlago, neodvisno testiranje, pregled arhitekture ali začasen izvedbeni projekt. Določite rezultate, omejitve dostopa, pričakovanja glede predaje in notranjo osebo, odgovorno za odločitve. Zunanje izvajanje ne odpravi potrebe po organizacijski odgovornosti. Za zajete subjekte člen 20 Direktive NIS 2 posebej obravnava odobritev in nadzor vodstva nad ukrepi za obvladovanje tveganj za kibernetsko varnost.

Odločitve med lastnim razvojem in nakupom naj vključujejo vzdrževanje, ne le razvoja. Lastna orodja zahtevajo nekoga, ki vzdržuje dovoljenja, preslikave, oblike dokazil, teste in spremembe izvornih sistemov. Komercialne možnosti ocenite po enakih zahtevah, vključno z možnostjo izvoza in sledljivostjo pregledov. Pri ocenjevanju uporabite reprezentativen potek dela, namesto da bi presojali le nadzorno ploščo; glejte kako izbrati programsko opremo GRC.

Širitev naj bo ponovljiva: ponazoritveni primer

Predpostavimo hipotetično programsko podjetje, ki upravlja en izdelek z osrednjim upravljanjem identitet in s prevzemom uvede drugi izdelek. Prevzeta ekipa uporablja ločen sistem identitet in dodatnega ponudnika gostovanja. To so ponazoritvene predpostavke, ne primer stranke Secanija.

Skupni cilj ostaja pravočasen odvzem dostopa. Podjetje lahko ponovno uporabi svojo osrednjo politiko, opis kontrole in merila pregleda. Dokazil o odstranitvi računov za prvi izdelek pa ne more ponovno uporabiti kot dokaza za prevzeto okolje.

Novi skrbnik storitve dokumentira aplikacije, administratorje, dobavitelje, obdelovane podatke in odvisnosti. IT zapiše, kateri računi sledijo osrednjemu procesu odhodov in kateri zahtevajo lokalno ukrepanje. Varnost pregleda vrzel; vodstvo odloči, ali bo financiralo takojšnjo integracijo ali odobrilo omejeno začasno ureditev.

Paket za vključitev vsebuje:

• Obseg storitve in popis odvisnosti.
• Pregledano oceno uporabnosti in tveganj.
• Dodeljene skupne kontrole in dokumentirane lokalne izvedbe.
• Začetna dokazila, pri čemer manjkajoči elementi postanejo naloge z odgovornimi osebami.
• Izjemo, ki beleži prizadete sisteme, nadomestne ukrepe, odobritelja, potek in odgovorno osebo za odpravo.

Dokler integracija ni dokončana, odgovorna oseba prevzete ekipe izvaja odobreni lokalni postopek in hrani njegova dokazila. Osrednje poročanje obe izvedbi prikazuje ločeno. Izjema velja le za imenovane sisteme in poteče, razen če je izrecno ponovno obravnavana.

Ko pride do integracije, pregledovalci potrdijo pokritost računov, posodobijo odvisnosti, zamenjajo zastarela dokazila in izjemo zaprejo šele po preverjanju izvedbe. To je ponovljiva širitev: ponovno uporabite metodo, za vsako storitev pa preglejte dejanska dejstva.

Uvajajte postopno z jasnimi merili sprejemljivosti

Izognite se selitvi celotnega podjetja, preden preizkusite, ali operativni model deluje. Izberite en reprezentativen obseg s skupno kontrolo, lokalno različico in razpoložljivimi odgovornimi osebami.

Najprej konsolidirajte trenutno stanje. Opredelite verodostojne politike, odstranite zastarele dvojnike, imenujte odgovorne osebe in obstoječa dokazila povežite s kontrolami. Merilo sprejemljivosti je preprosto: drug pregledovalec lahko razume obseg in odločitev, ne da bi moral izprašati prvotnega avtorja.

Nato standardizirajte ponavljajoče se zahteve in preglede. Opredelite merila dokončanja, poti eskalacije in odobritve izjem. Preizkusite dejanski cikel dokazil in razrešite nejasne predaje, preden dodate avtomatizacijo.

Nato avtomatizirajte najbolj ponavljajoče se korake. Preverite, ali avtomatizacija zmanjša celotno delo, vključno s popravki in pregledi. Neuspešno zbiranje naj postane vidno delo, ne pa tiho ohrani starega zelenega stanja.

Na koncu vzorec razširite na dodatne storitve in obveznosti. Dogovorite se, kaj sproži pregled: prevzemi, novi trgi, večji sistemi, spremembe dobaviteljev in incidenti. Kjer je relevantno, dodajte pomembno uporabo UI. Vsak sprožilec potrebuje pot v program, preden sprememba postane nevidna operativna zgodovina.

Spremljajte usklajevanje, ne le dokončanja

Visoka stopnja dokončanih nalog lahko obstaja skupaj z zastarelimi dokazili in nepregledanimi tveganji. Poročanje vodstvu naj pokaže, kje zaupanje slabi, ne le, koliko dejavnosti je bilo izvedenih.

Spremljajte zastarela dokazila, kontrole brez odgovornih oseb, zamujene odločitve, ponavljajoče se zahteve po istem gradivu in izjeme, ki se jim izteka rok. Naraščajoča števila lahko kažejo na strukturni problem, tudi kadar je večina nalog označena kot dokončana.

Merila prilagodite vprašanju, ki ga zastavljate. Med začetno konsolidacijo merite manjkajoče odgovornosti in čas odziva na zahteve za dokazila. Pri več storitvah merite vrzeli v lokalni izvedbi in čas, ki ga porabijo sodelujoči oddelki. Pri širšem obsegu spremljajte prodajne zamude zaradi zagotovil, čas vključitve storitev in ponavljajoče se ugotovitve.

Vsako merilo opredelite in primerjajte primerljive obsege. Hitrejši odgovori na vprašalnike niso napredek, če odgovori postanejo netočni. Manj zapisanih izjem ni napredek, če jih ekipe prenehajo prijavljati. Trende pregledujte skupaj z reprezentativnimi zapisi.

Vodstveni pregled naj se konča z odločitvami: financirati odpravo, prilagoditi rok, dodeliti odgovorno osebo ali ponovno preučiti sprejetje tveganja. Osrednje poročanje lahko postane naprednejše, ne da bi razblinilo lokalne odgovornosti.

Začnite z eno skupno kontrolo

V Secaniju lahko rastoča ekipa začne z enim osredotočenim obsegom, modelira njegove sisteme in ponudnike, dodeli odgovorne osebe in pregledovalce ter poveže dokazila z zahtevami, kontrolami in odločitvami. Njegov model delovnih prostorov in dovoljenj podpira upravljano sodelovanje v okviru organizacij, delovnih prostorov in obsegov. Predlogi s pomočjo UI ostanejo predmet človeškega pregleda, viri in odobritve pa ostanejo sledljivi.

Praktični naslednji korak je izbrati eno kontrolo, ki jo trenutno ločeno dokumentirata dve ekipi. Zapišite skupni cilj, opredelite obe lokalni izvedbi, povežite njuna dokazila in imenujte odgovorne osebe za odločitve. Pred širitvijo izvedite en cikel pregleda. Ta vaja pokaže, ali ima organizacija ponovljiv operativni model, in vodstvu da konkretno podlago za odločitev, kaj naslednje standardizirati, avtomatizirati ali okrepiti z viri.