Varne izhodiščne konfiguracije za NIS2 in DORA

Petkova popoldanska napačna konfiguracija, ki je postala vprašanje za upravni odbor

V petek ob 16.40 je vodja inženiringa na finančnotehnološki platformi odobril spremembo požarnega zidu, ki je bila videti rutinska. Za odpravljanje težav pri integraciji s ponudnikom plačilne analitike je bilo začasno odprto pravilo. V zahtevku je pisalo: »odstraniti po testiranju«. Test je uspel. Pravilo je ostalo.

Tri tedne pozneje je zunanje skeniranje odkrilo administratorski vmesnik, dostopen iz interneta. Strežnik je bil posodobljen s popravki. Večfaktorska avtentikacija (MFA) je bila uvedena za običajne uporabnike. Pregledovalnik ranljivosti ni označil kritičnega CVE. Vendar sistem še vedno ni bil varen, ker je njegova konfiguracija odstopala od odobrenega utrjenega stanja organizacije.

Do ponedeljka zjutraj je imel CISO vzporedno odprte štiri razprave:

1. Regulator je želel vedeti, ali je bila prizadeta operativna odpornost.
2. Pooblaščena oseba za varstvo podatkov je želela vedeti, ali so bili izpostavljeni osebni podatki.
3. Upravni odbor je želel vedeti, zakaj se »začasne« spremembe ne zaznavajo.
4. Notranji presojevalec ISO/IEC 27001:2022 je želel dokazila, da so varne izhodiščne konfiguracije opredeljene, odobrene, uvedene in spremljane.

Tu številni varnostni programi odkrijejo neprijetno resnico. Varna konfiguracija ni zgolj tehnični kontrolni seznam za utrjevanje. Leta 2026 so varne izhodiščne konfiguracije vprašanje upravljanja, kibernetske higiene, IKT-tveganj, dokazil za presojo in odgovornosti upravnega odbora.

Druga različica iste težave se pojavlja v številnih reguliranih organizacijah. Maria, CISO rastočega B2B ponudnika obdelave plačil, ima odlične inženirje, posodobljene sisteme in dobre prakse za oblak. Vendar presoja pripravljenosti za NIS2 in DORA izpostavi eno rdečo ugotovitev: pomanjkanje formaliziranih varnih izhodiščnih konfiguracij. Njena ekipa zna utrditi strežnike, vendar je velik del tega znanja v glavah inženirjev, ne v odobrenih standardih, avtomatiziranih preverjanjih ali paketih dokazil.

Te vrzeli ni več mogoče zagovarjati. NIS2 zahteva, da organi upravljanja odobrijo in nadzorujejo ukrepe za upravljanje kibernetskih tveganj. DORA zahteva dokumentiran okvir upravljanja IKT-tveganj in odporne operacije IKT. GDPR zahteva ustrezne tehnične in organizacijske ukrepe. ISO/IEC 27001:2022 zahteva izbiro kontrol na podlagi tveganj, implementacijo, spremljanje, presojo in nenehno izboljševanje.

Varne izhodiščne konfiguracije povežejo vse te obveznosti v en praktičen sistem kontrol: opredeliti izhodiščno konfiguracijo, dodeliti lastništvo, jo uveljaviti pri dodeljevanju dostopa oziroma uvedbi sistemov, upravljati izjeme, zaznavati odklone, zagotoviti dokazila in izboljševati po presojah ali incidentih.

Kot Clarysecov Zenith Blueprint: 30-koračni načrt za presojevalce navaja v fazi Kontrole v praksi, 19. korak, Tehnološke kontrole I:

»Veliko kršitev ni posledica napak programske opreme, temveč slabih konfiguracijskih odločitev. Privzeta gesla ostanejo nespremenjena, nezavarovane storitve so omogočene, nepotrebna vrata so odprta ali pa so sistemi brez utemeljitve izpostavljeni internetu.«

Ta stavek pojasni, zakaj so varne izhodiščne konfiguracije zdaj ključna kontrola odpornosti. Določajo, kaj pomeni varno, še preden to vpraša presojevalec, regulator, stranka ali napadalec.

Kaj varna izhodiščna konfiguracija dejansko pomeni

Varna izhodiščna konfiguracija je odobren, dokumentiran in ponovljiv nabor varnostnih nastavitev za določeno vrsto sistema. Uporabi se lahko za strežnike Windows, gostitelje Linux, omrežne naprave, najemnike SaaS, shrambo v oblaku, gruče Kubernetes, podatkovne baze, požarne zidove, končne točke, platforme identitet, naprave interneta stvari in operativno tehnologijo.

Močna izhodiščna konfiguracija odgovori na praktična vprašanja:

• Katere storitve so privzeto onemogočene?
• Katera vrata so lahko izpostavljena navzven?
• Katere nastavitve avtentikacije in MFA so obvezne?
• Katere nastavitve beleženja morajo biti omogočene?
• Katere nastavitve šifriranja so zahtevane?
• Kateri administratorski vmesniki so omejeni?
• Kateri viri v oblaku so lahko javni in s čigavo odobritvijo?
• Katera odstopanja zahtevajo sprejem tveganja?
• Kako pogosto preverjamo odklon konfiguracije?
• Katera dokazila dokazujejo, da izhodiščna konfiguracija deluje?

Najpogostejša napaka je obravnava izhodiščnih konfiguracij kot inženirskih preferenc namesto kot upravljanih kontrol. Kontrolni seznam administratorja Linux, wiki stran arhitekta za oblak in konvencija omrežnega inženirja za požarne zidove so lahko koristni, vendar postanejo preverljivi šele, ko so odobreni, preslikani na tveganje, dosledno uporabljeni in spremljani.

Zato je ISO/IEC 27001:2022 tako uporaben okvir. Klavzule 4.1 do 4.3 od organizacij zahtevajo razumevanje notranjih in zunanjih vprašanj, zainteresiranih strani in obsega ISMS, vključno z zakonskimi, regulativnimi, pogodbenimi zahtevami in zahtevami tretjih oseb. Klavzuli 6.1.2 in 6.1.3 zahtevata oceno tveganja informacijske varnosti, obravnavo tveganja, izbiro kontrol, izjavo o uporabnosti in odobritev lastnika tveganja. Klavzuli 8.2 in 8.3 zahtevata, da se ocene tveganj in obravnava tveganj ponavljajo v načrtovanih intervalih ali po pomembnih spremembah.

Priloga A nato tehnično pričakovanje konkretizira s kontrolo A.8.9 Upravljanje konfiguracije, ki jo podpirajo evidenca sredstev, upravljanje ranljivosti, upravljanje sprememb, beleženje, spremljanje, nadzor dostopa, kriptografija, uporaba storitev v oblaku in dokumentirani operativni postopki.

Rezultat je preprosta, vendar močna upravljavska izjava: če organizacija ne more pokazati, kaj varno pomeni za vsako večjo vrsto sistema, ne more prepričljivo dokazati kibernetske higiene po NIS2, nadzora IKT-tveganj po DORA, odgovornosti po GDPR ali učinkovitosti kontrol po ISO/IEC 27001:2022.

Zakaj NIS2, DORA in GDPR naredijo izhodiščne konfiguracije neizogibne

NIS2, DORA in GDPR uporabljajo različen jezik, vendar se stekajo v isto operativno zahtevo: sistemi morajo biti varno konfigurirani, stalno spremljani in upravljani z odgovornim upravljanjem tveganj.

NIS2 Article 20 zahteva, da organi upravljanja bistvenih in pomembnih subjektov odobrijo ukrepe za upravljanje kibernetskih tveganj, nadzorujejo njihovo izvajanje in prejmejo usposabljanje za kibernetsko varnost. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe. Varne izhodiščne konfiguracije podpirajo Article 21(2)(a) politike o analizi tveganj in varnosti informacijskih sistemov, Article 21(2)(e) varnost pri nabavi, razvoju in vzdrževanju omrežnih in informacijskih sistemov, vključno z obravnavo ranljivosti, Article 21(2)(f) politike in postopke za ocenjevanje učinkovitosti, Article 21(2)(g) osnovno kibernetsko higieno in usposabljanje za kibernetsko varnost, Article 21(2)(h) kriptografijo, Article 21(2)(i) nadzor dostopa in upravljanje sredstev ter Article 21(2)(j) večfaktorsko avtentikacijo in varne komunikacije.

DORA se uporablja od 17. januarja 2025 in deluje kot sektorsko specifičen pravilnik operativne odpornosti za zajete finančne subjekte. Articles 5 in 6 zahtevata upravljanje in dokumentiran okvir upravljanja IKT-tveganj. Article 8 zahteva identifikacijo sredstev IKT, informacijskih sredstev, poslovnih funkcij, podprtih z IKT, in odvisnosti. Article 9 zahteva ukrepe zaščite in preprečevanja, vključno z varnostnimi politikami, postopki, protokoli in orodji za sisteme IKT, varen prenos podatkov, nadzor dostopa, močno avtentikacijo, zaščito kriptografskih ključev, upravljanje sprememb, nameščanje popravkov in posodobitve. Articles 10 do 14 model razširjajo na zaznavanje, odzivanje, obnovitev, varnostno kopiranje, povrnitev delovanja, učenje in komuniciranje.

GDPR doda vidik zasebnosti. Articles 5 in 32 zahtevata celovitost, zaupnost, varnost obdelave in odgovornost z ustreznimi tehničnimi in organizacijskimi ukrepi. Javni vsebniki za shranjevanje v oblaku, preveč izpostavljene podatkovne baze, nezavarovane privzete nastavitve in prekomeren administratorski dostop niso le infrastrukturne slabosti. Postanejo lahko neuspehi pri varstvu osebnih podatkov.

Enoten program varnih izhodiščnih konfiguracij lahko podpira vse tri režime brez ustvarjanja podvojenih tokov dokazil.

Clarysecov model izhodiščnih konfiguracij: politika, postopek in platformna dokazila

Clarysec varno konfiguracijo obravnava kot ponovljiv sistem kontrol, ne kot enkratni projekt utrjevanja. Izhodiščna konfiguracija mora biti pooblaščena s politiko, prevedena v postopke, uvedena s tehničnimi kontrolami in dokazana z dokazili.

Politika informacijske varnosti to pričakovanje določa na ravni podjetja:

»Organizacija mora vzdrževati minimalni osnovni nabor kontrol, izpeljan iz Priloge A ISO/IEC 27001, po potrebi dopolnjen s kontrolami iz ISO/IEC 27002, NIST SP 800-53 in COBIT 2019.«
Iz razdelka »Obravnava tveganj in izjeme«, klavzula politike 7.2.1.

Ta klavzula preprečuje, da bi utrjevanje konfiguracij postalo zbirka osebnih preferenc. Minimalni osnovni nabor kontrol zasidra v priznane okvire.

Za okolja v oblaku Politika uporabe storitev v oblaku zahtevo zoži:

»Vsa okolja v oblaku morajo biti skladna z dokumentirano izhodiščno konfiguracijo, ki jo odobri varnostni arhitekt za oblak.«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.3.1.

Politika spremljanja presoj in skladnosti nato izhodiščno konfiguracijo pretvori v spremljano kontrolo:

»Za spremljanje skladnosti konfiguracij, upravljanja ranljivosti, stanja popravkov in privilegiranega dostopa se morajo uporabljati avtomatizirana orodja.«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.4.1.

Konfiguracija je neločljivo povezana tudi z upravljanjem ranljivosti in popravkov. Politika upravljanja ranljivosti in popravkov določa:

»Odprava ranljivosti mora biti usklajena z izhodiščno konfiguracijo in standardi utrjevanja sistemov.«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.4.1.

Ta točka je pomembna. Sistem je lahko posodobljen s popravki, pa še vedno ni varen, če je omogočen SMBv1, če so administratorski vmesniki izpostavljeni, če je beleženje onemogočeno ali če ostanejo v veljavi šibke nastavitve avtentikacije. V Zenith Controls: vodniku za navzkrižno skladnost je upravljanje konfiguracije obravnavano kot preventivna kontrola, ki varuje zaupnost, celovitost in razpoložljivost, z operativno zmožnostjo varne konfiguracije. Zenith Controls pojasnjuje tudi odvisnost med upravljanjem konfiguracije in upravljanjem ranljivosti:

»Upravljanje ranljivosti je odvisno od znanih konfiguracij. Brez opredeljene izhodiščne konfiguracije ni mogoče zagotoviti, da se popravki uporabljajo dosledno.«

To je dokazna zgodba, ki jo presojevalci in regulatorji vse pogosteje pričakujejo: sistem kontrol, ne izolirana tehnična naloga.

Preslikava ISO/IEC 27001:2022 A.8.9 na podporne kontrole

Kontrola A.8.9 Upravljanje konfiguracije iz Priloge A ISO/IEC 27001:2022 je sidro, vendar je ne bi smeli obravnavati kot majhen samostojen dokument. Odvisna je od širše družine kontrol.

Zaradi tega medkontrolnega razmerja Clarysec priporoča upravljanje varne konfiguracije kot zmožnosti ISMS z lastniki, dokazili, metrikami in poročanjem vodstvu.

Širša preslikava pomaga isti program izhodiščnih konfiguracij prenesti v druge okvire.

Praktična struktura izhodiščne konfiguracije, ki jo lahko uvedete ta mesec

Najpogostejša napaka je poskus napisati popoln 80-stranski standard utrjevanja, še preden se karkoli uveljavi. Začnite z minimalno, vendar preverljivo izhodiščno konfiguracijo za vsako večjo tehnološko družino, nato jo z avtomatizacijo in pregledi postopoma dozorevajte.

Za izhodiščno konfiguracijo shrambe v oblaku lahko prva različica vključuje privzeto onemogočen javni dostop, omogočeno šifriranje v mirovanju, omogočeno beleženje dostopa, administratorski dostop omejen na odobrene skupine, MFA zahtevan za privilegiran dostop do konzole, omogočeno nadzorovanje različic, kadar to zahtevajo zahteve za obnovitev, replikacijo omejeno na odobrene regije in spremembe izvedene samo prek odobrenih cevovodov infrastrukture kot kode.

Za izhodiščno konfiguracijo Windows Server 2022, ki podpira obdelavo plačil, lahko prva različica vključuje onemogočen SMBv1, onemogočene nebistvene storitve, RDP omejen na utrjen odskočni strežnik, Windows Defender Firewall omogočen s pravili privzetega zavračanja, nadzorovane lokalne administratorske račune, posredovanje dnevnikov dogodkov v SIEM, omogočeno zaščito končnih točk in administratorske spremembe povezane z odobrenimi zahtevki.

Za vsako izhodiščno konfiguracijo pripravite majhen paket dokazil:

1. Odobren dokument izhodiščne konfiguracije.
2. Posnetek zaslona ali izvoženo politiko, ki prikazuje uporabljeno konfiguracijo.
3. Seznam sredstev, zajetih z izhodiščno konfiguracijo.
4. Zahtevek za spremembo, ki prikazuje, kako se odobrijo posodobitve.
5. Poročilo o skladnosti konfiguracije ali ročni zapis pregleda.

To je neposredno usklajeno z Zenith Blueprint, faza Kontrole v praksi, 19. korak, kjer Clarysec organizacijam svetuje, naj vzpostavijo kontrolne sezname konfiguracij za glavne vrste sistemov, pri dodeljevanju oziroma uvedbi dosledno uporabijo nastavitve, po možnosti z avtomatizacijo, nato pa redno presojajo uvedene sisteme. Blueprint podaja tudi praktično metodo presoje:

»Izberite nekaj reprezentativnih sistemov (npr. en strežnik, eno stikalo, en osebni računalnik končnega uporabnika) in preverite, da njihova konfiguracija ustreza vaši varni izhodiščni konfiguraciji. Dokumentirajte odstopanja in odpravo.«

Za mala in srednja podjetja je tak reprezentativni vzorčni pristop pogosto najhitrejša pot od neformalnega utrjevanja do dokazil, pripravljenih za presojo.

Primeri utrjevanja v malih in srednjih podjetjih, ki hitro zmanjšajo tveganje

Varna konfiguracija ni le vprašanje oblaka v velikih podjetjih. Mala in srednja podjetja pogosto največje zmanjšanje tveganja dosežejo z nekaj jasnimi pravili izhodiščnih konfiguracij.

Politika varnosti omrežja - SME določa:

»Javnemu internetu so lahko izpostavljena samo bistvena vrata (npr. HTTPS, VPN); vsa druga morajo biti zaprta ali filtrirana«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.3.

Zahteva tudi disciplino pri spremembah:

»Vse spremembe omrežnih konfiguracij (pravila požarnega zidu, ACL stikal, usmerjevalne tabele) morajo slediti dokumentiranemu procesu upravljanja sprememb«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.9.1.

Vzpostavlja tudi ritem pregledov:

»Ponudnik IT-podpore mora izvesti letni pregled pravil požarnega zidu, omrežne arhitekture in konfiguracij brezžičnih omrežij«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.6.1.

Izhodiščne konfiguracije končnih točk zahtevajo enako pozornost. Clarysecova Politika zaščite končnih točk pred zlonamerno programsko opremo - SME določa:

»Naprave morajo onemogočiti zastarele protokole (npr. SMBv1), ki jih lahko izkoristi zlonamerna programska oprema«
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.2.1.3.

V okoljih IoT in OT so nezavarovane privzete nastavitve še naprej ponavljajoča se izpostavljenost. Varnostna politika za internet stvari (IoT) / operativno tehnologijo (OT) - SME določa:

»Privzeta ali trdo kodirana gesla je treba spremeniti, preden se naprave aktivirajo«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.2.

Te klavzule politik niso abstraktne izjave. So zahteve izhodiščnih konfiguracij, ki jih je mogoče testirati, dokazovati in spremljati. Za malo ali srednje podjetje, ki se pripravlja na skrbni pregled strank, preglede dobaviteljev po NIS2, kibernetsko zavarovanje ali certifikacijo ISO/IEC 27001:2022, ustvarijo takojšnjo vrednost.

Obravnava izjem: kontrola, ki loči zrelost od dokumentacije

Vsaka izhodiščna konfiguracija bo imela izjeme. Zastarela aplikacija lahko zahteva star protokol. Dobaviteljska naprava morda ne podpira prednostne nastavitve šifriranja. Za migracijo je lahko potrebno začasno odprtje požarnega zidu. Vprašanje ni, ali izjeme obstajajo. Vprašanje je, ali so upravljane.

Zrela evidenca izjeme vključuje:

• Zahtevo izhodiščne konfiguracije, ki se krši.
• Poslovno utemeljitev.
• Prizadeto sredstvo in lastnika.
• Oceno tveganja.
• Kompenzacijske kontrole.
• Odobritveni organ.
• Datum poteka.
• Zahtevo glede spremljanja.
• Načrt odprave.

Tu se obravnava tveganja po ISO/IEC 27001:2022 in sorazmernost po DORA dopolnjujeta. ISO/IEC 27001:2022 zahteva, da so odločitve o kontrolah utemeljene z oceno tveganja, obravnavo tveganja, izjavo o uporabnosti in odobritvijo lastnika tveganja. DORA omogoča sorazmerno implementacijo glede na velikost, profil tveganja ter naravo, obseg in kompleksnost storitev, vendar še vedno pričakuje dokumentirano upravljanje IKT-tveganj, spremljanje, neprekinjenost, testiranje in ozaveščanje.

Sorazmernost ni dovoljenje za preskok izhodiščnih konfiguracij. Je zahteva, da se te pametno prilagodijo obsegu.

Za mikro ali manjši finančni subjekt v poenostavljenem okviru upravljanja IKT-tveganj je lahko izhodiščna konfiguracija jedrnata in podprta z ročnim vzorčenjem. Pri večjem finančnem subjektu bo isto področje verjetno zahtevalo avtomatizirana konfiguracijska preverjanja, vključitev notranje revizije, letno testiranje in poročanje organu upravljanja.

Politika upravljanja sprememb organizacije opozarja tudi, naj spremljajo:

»Odklon konfiguracije ali poseganje po odobrenih spremembah«
Iz razdelka »Uveljavljanje in skladnost«, klavzula politike 8.1.2.3.

Ta izraz povezuje nadzor sprememb z zaznavanjem odklonov. Sprememba je lahko odobrena, pa še vedno povzroči tveganje, če se uvedeno stanje razlikuje od odobrenega stanja ali če začasna nastavitev ostane po zaprtju okna izvedbe spremembe.

Vzpostavitev ene dokazne sledi za številne obveznosti skladnosti

Varna izhodiščna konfiguracija ne bi smela ustvariti petih ločenih tokov dela za skladnost. Clarysecov model uporablja eno dokazno sled, preslikano na več obveznosti.

Ključna je sledljivost. Zenith Blueprint, faza Presoja, pregled in izboljševanje, 24. korak, organizacijam nalaga posodobitev izjave o uporabnosti in njeno navzkrižno preverjanje z načrtom obravnave tveganj. Če je kontrola uporabna, potrebujete utemeljitev. Ta utemeljitev mora biti povezana s tveganjem, zakonsko obveznostjo, pogodbeno zahtevo ali poslovno potrebo.

Za varno konfiguracijo mora vnos v izjavi o uporabnosti (SoA) za A.8.9 sklicevati na standard varne izhodiščne konfiguracije, zajete kategorije sredstev, lastnike izhodiščnih konfiguracij, postopek upravljanja sprememb, metodo spremljanja, postopek izjem, ritem pregledov in obveznosti navzkrižne skladnosti, kot so NIS2 Article 21, DORA Articles 6, 8 in 9, GDPR Article 32 ter zaveze strankam.

Kako bodo presojevalci testirali varne izhodiščne konfiguracije

Varna konfiguracija je za presojevalce privlačna, ker je bogata z dokazili. Testirati jo je mogoče z dokumenti, intervjuji, vzorčenjem in tehničnim pregledom.

Praktična vprašanja so predvidljiva:

• Ali pri namestitvi novih strežnikov uporabljate kontrolni seznam utrjevanja?
• Kako preprečite izvajanje nezavarovanih storitev, kot je Telnet, na usmerjevalnikih?
• Ali so viri shrambe v oblaku privzeto zasebni?
• Kdo lahko odobri odstopanje od izhodiščne konfiguracije?
• Kako zaznate odklon po spremembi?
• Ali lahko pokažete nedavni pregled konfiguracije?
• Ali lahko pokažete, da je bilo zaznano odstopanje odpravljeno?
• Ali so omrežne konfiguracije in konfiguracije v oblaku varnostno kopirane in upravljane z različicami?
• Ali so postopki povrnitve dokumentirani in testirani?

Najmočnejše organizacije vzdržujejo paket dokazil izhodiščnih konfiguracij za vsako večjo kategorijo sistemov. To skrajša presoje, izboljša odzive na skrbni pregled strank in pomaga vodstvu razumeti dejansko uspešnost kontrol.

Pretvorite odklon konfiguracije v metriko kibernetske higiene za upravni odbor

Upravni odbori ne potrebujejo vsakega pravila požarnega zidu. Vedeti pa morajo, ali se kibernetska higiena izboljšuje ali slabša.

Uporabna nadzorna plošča varne konfiguracije vključuje:

• Delež sredstev, preslikanih na odobreno izhodiščno konfiguracijo.
• Delež sredstev, ki prestanejo preverjanja izhodiščne konfiguracije.
• Število kritičnih odstopanj od izhodiščne konfiguracije.
• Povprečno starost odprtih odstopanj.
• Število pretečenih izjem.
• Število zaznanih nepooblaščenih konfiguracijskih sprememb.
• Delež privilegiranih konfiguracijskih sprememb z odobrenimi zahtevki.
• Izjeme javne izpostavljenosti v oblaku.
• Status pregleda izhodiščnih konfiguracij po tehnoloških družinah.

Te metrike podpirajo vrednotenje uspešnosti po ISO/IEC 27001:2022, nadzor vodstva po NIS2 in poročanje o IKT-tveganjih po DORA. Naravno se preslikajo tudi na rezultate upravljanja v NIST CSF 2.0 ter cilje spremljanja in skladnosti v COBIT 2019.

Pomaga preprosto pravilo za izvršno vodstvo: noben kritični sistem ne preide v produkcijo brez dokazil o izhodiščni konfiguraciji. To je mogoče uveljaviti z upravljanjem sprememb, kontrolnimi točkami CI/CD, preverjanji politik v oblaku, pregledom infrastrukture kot kode, skladnostjo MDM, uveljavljanjem GPO ali pregledom omrežnih konfiguracij. Raven zrelosti se lahko razlikuje, vendar se logika kontrole ne sme.

90-dnevni priročnik za varne izhodiščne konfiguracije

Če začenjate iz nič, ne poskušajte rešiti vsake konfiguracijske težave naenkrat. Uporabite 90-dnevni načrt.

Dnevi 1 do 30: opredelite minimalno izhodiščno konfiguracijo

Identificirajte kritične kategorije sredstev. Za vsako dodelite tehničnega lastnika, lastnika tveganja in odobritveni organ. Ustvarite prvo izhodiščno konfiguracijo za nastavitve, ki so najpomembnejše za odpornost proti izsiljevalski programski opremi, izpostavljenost v oblaku, privilegiran dostop, beleženje, šifriranje in varstvo podatkov.

Vzpostavite register izhodiščnih konfiguracij in ga preslikajte na obseg ISMS, register tveganj in izjavo o uporabnosti. Če za vas velja NIS2, ugotovite, ali ste bistveni ali pomembni subjekt oziroma ali stranke pričakujejo kibernetsko higieno, usklajeno z NIS2. Če ste finančni subjekt po DORA, identificirajte, katera sredstva IKT podpirajo kritične ali pomembne funkcije. Če obdelujete osebne podatke, preslikajte sisteme na dejavnosti obdelave po GDPR in kategorije podatkov.

Dnevi 31 do 60: uveljavite in zberite dokazila

Uporabite izhodiščno konfiguracijo na vzorcu visoko tveganih sistemov. Kjer je mogoče, uporabite avtomatizacijo, vendar ne čakajte na popolna orodja. Izvozite konfiguracije, zajemite posnetke zaslona, shranite nastavitve politik in evidentirajte zahtevke za spremembe.

Za vsako izjemo ustvarite zapis tveganja z datumom poteka. Za vsako odstopanje ustvarite zahtevek za odpravo.

Dnevi 61 do 90: spremljajte, poročajte in izboljšujte

Izvedite pregled konfiguracije. Vzorčite en strežnik, eno končno točko, eno omrežno napravo in eno okolje v oblaku. Primerjajte dejanske nastavitve z odobreno izhodiščno konfiguracijo. Dokumentirajte odstopanja in korektivne ukrepe.

Poročajte vodstvu o skladnosti z izhodiščnimi konfiguracijami. Posodobite izjavo o uporabnosti in načrt obravnave tveganj. Ponavljajoča se odstopanja vključite v analizo temeljnega vzroka. Če je napačna konfiguracija povzročila incident ali k njemu prispevala, posodobite ustrezno izhodiščno konfiguracijo kot del pridobljenih izkušenj.

To presojevalcem zagotovi nekaj testabilnega, regulatorjem nekaj razumljivega in vodstvu nekaj, kar je mogoče upravljati.

Zaključna misel: varna konfiguracija je kibernetska higiena z dokazili

NIS2 uporablja jezik ukrepov za upravljanje kibernetskih tveganj in osnovne kibernetske higiene. DORA uporablja jezik IKT-tveganj, odpornosti, spremljanja, neprekinjenosti in testiranja. GDPR uporablja jezik ustreznih ukrepov in odgovornosti. ISO/IEC 27001:2022 uporablja jezik obravnave tveganja, kontrol, dokumentiranih informacij, vrednotenja uspešnosti in nenehnega izboljševanja.

Varne izhodiščne konfiguracije povezujejo vse te jezike.

Dokazujejo, da sistemi niso uvedeni z nezavarovanimi privzetimi nastavitvami. Dokazujejo, da so spremembe nadzorovane. Dokazujejo, da se odkloni zaznavajo. Dokazujejo, da so izjeme sprejete na podlagi tveganja. Dokazujejo, da dokazila obstajajo, še preden jih zahteva presojevalec.

Najpomembneje pa je, da zmanjšujejo dejansko operativno tveganje. Petkovo popoldansko pravilo požarnega zidu, javni vsebnik za shranjevanje v oblaku, pozabljena nastavitev SMBv1, privzeto geslo naprave IoT in administratorska konzola brez beleženja niso teoretične revizijske ugotovitve. So praktične točke odpovedi.

Clarysec organizacijam pomaga te točke odpovedi pretvoriti v nadzorovane, spremljane in preverljive izhodiščne konfiguracije.

Naslednji koraki

Če mora vaša organizacija dokazati varno konfiguracijo za ISO/IEC 27001:2022, kibernetsko higieno po NIS2, upravljanje IKT-tveganj po DORA, odgovornost po GDPR ali zagotavljanje zaupanja naročnikov, začnite s Clarysecovim naborom orodij:

• Uporabite Zenith Blueprint: 30-koračni načrt za presojevalce za implementacijo upravljanja konfiguracije v fazi Kontrole v praksi, 19. korak, in njegovo validacijo v fazi Presoja, pregled in izboljševanje, 24. korak.
• Uporabite Zenith Controls: vodnik za navzkrižno skladnost za preslikavo upravljanja konfiguracije na podporne kontrole ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 in metodologije presoje.
• Uporabite politike Clarysec, kot so Politika informacijske varnosti, Politika uporabe storitev v oblaku, Politika spremljanja presoj in skladnosti, Politika upravljanja ranljivosti in popravkov, Politika varnosti omrežja - SME, Politika zaščite končnih točk pred zlonamerno programsko opremo - SME in Varnostna politika za internet stvari (IoT) / operativno tehnologijo (OT) - SME, da opredelite, uveljavite in dokažete zahteve svojih izhodiščnih konfiguracij.

Varna izhodiščna konfiguracija ni zgolj kontrolni seznam utrjevanja. Je dokaz, da vaša organizacija ve, kako je videti varno stanje, ga uporablja dosledno in ga lahko dokaže, ko je to pomembno.