Drošas pamatkonfigurācijas NIS2 un DORA vajadzībām

Piektdienas pēcpusdienas nepareizā konfigurācija, kas kļuva par valdes jautājumu

Piektdien plkst. 16.40 finanšu tehnoloģiju platformas inženierijas vadītājs apstiprināja šķietami rutīnas ugunsmūra izmaiņu. Lai novērstu problēmu integrācijā ar maksājumu analītikas pakalpojumu sniedzēju, tika atvērts pagaidu noteikums. Pieteikumā bija norādīts: “noņemt pēc testēšanas”. Tests bija sekmīgs. Noteikums palika spēkā.

Pēc trim nedēļām ārēja skenēšana atklāja, ka administratīvā saskarne ir sasniedzama no interneta. Serverim bija uzstādīti ielāpi. MFA bija ieviesta parastajiem lietotājiem. Ievainojamību skeneris neatzīmēja kritisku CVE. Tomēr sistēma joprojām nebija droša, jo tās konfigurācija bija novirzījusies no organizācijas apstiprinātā drošā konfigurācijas stāvokļa.

Līdz pirmdienas rītam informācijas drošības vadītājs (CISO) vienlaikus risināja četras sarunas:

1. Regulators vēlējās zināt, vai ir ietekmēta darbības noturība.
2. Datu aizsardzības speciālists vēlējās zināt, vai ir notikusi personas datu eksponēšana.
3. Valde vēlējās zināt, kāpēc “pagaidu” izmaiņas netika atklātas.
4. ISO/IEC 27001:2022 iekšējais auditors vēlējās pierādījumus, ka drošas pamatkonfigurācijas ir definētas, apstiprinātas, ieviestas un uzraudzītas.

Šajā brīdī daudzas drošības programmas atklāj neērtu patiesību. Droša konfigurācija nav tikai tehnisks drošās konfigurēšanas kontrolsaraksts. 2026. gadā drošas pamatkonfigurācijas ir pārvaldības jautājums, kiberdrošības higiēnas jautājums, IKT riska jautājums, audita pierādījumu jautājums un valdes pārskatatbildības jautājums.

Tās pašas problēmas cita versija atkārtojas daudzās regulētās organizācijās. Marijai, augoša B2B maksājumu apstrādātāja CISO, ir spēcīgi inženieri, sistēmas ar uzstādītiem ielāpiem un mākoņvides labākā prakse. Taču gatavības izvērtējums NIS2 un DORA vajadzībām izceļ vienu sarkanu konstatējumu: formalizētu drošu pamatkonfigurāciju trūkumu. Viņas komanda zina, kā droši konfigurēt serverus, taču liela daļa šo zināšanu atrodas inženieru galvās, nevis apstiprinātos standartos, automatizētās pārbaudēs vai pierādījumu paketēs.

Šī plaisa vairs nav aizstāvama. NIS2 prasa, lai vadības struktūras apstiprina un pārrauga kiberdrošības risku pārvaldības pasākumus. DORA prasa dokumentētu IKT risku pārvaldības ietvaru un noturīgas IKT operācijas. GDPR prasa atbilstošus tehniskos un organizatoriskos pasākumus. ISO/IEC 27001:2022 prasa uz risku balstītu kontroles pasākumu atlasi, ieviešanu, uzraudzību, auditu un nepārtrauktu pilnveidi.

Drošas pamatkonfigurācijas savieno visus šos pienākumus vienā praktiskā kontroles sistēmā: definēt pamatkonfigurāciju, piešķirt atbildību, piemērot to piekļuves piešķiršanas vai sistēmas izvietošanas laikā, pārvaldīt izņēmumus, atklāt konfigurācijas novirzi, pierādīt ar pierādījumiem un pilnveidot pēc auditiem vai incidentiem.

Kā Clarysec Zenith Blueprint: Auditora 30 soļu ceļkarte to formulē posmā “Kontroles pasākumi darbībā”, 19. solī, “Tehnoloģiskie kontroles pasākumi I”:

“Daudzi pārkāpumi nerodas programmatūras trūkumu dēļ; tie rodas nepareizu konfigurācijas izvēļu dēļ. Noklusējuma paroles netiek nomainītas, ir iespējoti nedroši pakalpojumi, atvērti nevajadzīgi porti vai sistēmas bez pamatojuma ir eksponētas internetam.”

Šis teikums paskaidro, kāpēc drošas pamatkonfigurācijas tagad ir būtisks noturības kontroles pasākums. Tās nosaka, ko nozīmē drošs stāvoklis, pirms to jautā auditors, regulators, klients vai uzbrucējs.

Kas patiesībā ir droša pamatkonfigurācija

Droša pamatkonfigurācija ir apstiprināts, dokumentēts un atkārtojams drošības iestatījumu kopums konkrētam sistēmas tipam. Tā var attiekties uz Windows serveriem, Linux resursdatoriem, tīkla ierīcēm, SaaS nomniekiem, mākoņkrātuvi, Kubernetes klasteriem, datubāzēm, ugunsmūriem, galapunktu ierīcēm, identitātes platformām, IoT ierīcēm un operatīvajām tehnoloģijām.

Spēcīga pamatkonfigurācija atbild uz praktiskiem jautājumiem:

• Kuri pakalpojumi pēc noklusējuma ir atspējoti?
• Kurus portus drīkst eksponēt ārēji?
• Kuri autentifikācijas un MFA iestatījumi ir obligāti?
• Kuri žurnalēšanas iestatījumi jāiespējo?
• Kuri šifrēšanas iestatījumi ir nepieciešami?
• Kuras administratīvās saskarnes ir ierobežotas?
• Kuri mākoņresursi drīkst būt publiski, un ar kura apstiprinājumu?
• Kurām atkāpēm nepieciešama riska pieņemšana?
• Cik bieži pārbaudām konfigurācijas novirzi?
• Kādi pierādījumi apliecina, ka pamatkonfigurācija darbojas?

Visbiežākā kļūda ir pamatkonfigurāciju uztveršana kā inženierijas izvēles, nevis pārvaldīti kontroles pasākumi. Linux administratora kontrolsaraksts, mākoņarhitekta wiki lapa un tīkla inženiera ugunsmūra konvencijas var būt noderīgas, taču tās nekļūst auditējamas, kamēr nav apstiprinātas, kartētas pret riskiem, konsekventi piemērotas un uzraudzītas.

Tieši tāpēc ISO/IEC 27001:2022 ir tik noderīgs atskaites punkts. 4.1.–4.3. punkti prasa organizācijām izprast iekšējos un ārējos jautājumus, ieinteresētās puses un ISMS darbības jomu, tostarp juridiskās, regulatīvās, līgumiskās un trešo pušu prasības. 6.1.2. un 6.1.3. punkti prasa informācijas drošības risku izvērtēšanu, riska apstrādi, kontroles pasākumu atlasi, Piemērojamības paziņojumu un riska īpašnieka apstiprinājumu. 8.2. un 8.3. punkti prasa risku izvērtēšanu un riska apstrādi atkārtot plānotos intervālos vai pēc būtiskām izmaiņām.

A pielikums tehnisko prasību padara konkrētu ar A.8.9 Konfigurācijas pārvaldība, ko atbalsta aktīvu uzskaite, ievainojamību pārvaldība, izmaiņu pārvaldība, žurnalēšana, uzraudzība, piekļuves kontrole, kriptogrāfija, mākoņpakalpojumu izmantošana un dokumentētas ekspluatācijas procedūras.

Rezultāts ir vienkāršs, bet spēcīgs pārvaldības apgalvojums: ja organizācija nevar parādīt, ko drošs stāvoklis nozīmē katram būtiskajam sistēmas tipam, tā nevar pārliecinoši pierādīt kiberdrošības higiēnu saskaņā ar NIS2, IKT riska kontroli saskaņā ar DORA, pārskatatbildību saskaņā ar GDPR vai kontroles efektivitāti saskaņā ar ISO/IEC 27001:2022.

Kāpēc NIS2, DORA un GDPR padara pamatkonfigurācijas neizbēgamas

NIS2, DORA un GDPR izmanto atšķirīgu valodu, taču tie saplūst vienā un tajā pašā operacionālajā prasībā: sistēmām jābūt droši konfigurētām, nepārtraukti uzraudzītām un pārvaldītām ar pārskatatbildīgu risku pārvaldību.

NIS2 Article 20 prasa, lai būtisko un svarīgo vienību vadības struktūras apstiprina kiberdrošības risku pārvaldības pasākumus, pārrauga ieviešanu un saņem kiberdrošības apmācību. Article 21 prasa atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus. Drošas pamatkonfigurācijas atbalsta Article 21(2)(a) politikas par risku analīzi un informācijas sistēmu drošību, Article 21(2)(e) drošību tīkla un informācijas sistēmu iegādē, izstrādē un uzturēšanā, tostarp ievainojamību apstrādi, Article 21(2)(f) politikas un procedūras efektivitātes izvērtēšanai, Article 21(2)(g) pamata kiberdrošības higiēnu un kiberdrošības apmācību, Article 21(2)(h) kriptogrāfiju, Article 21(2)(i) piekļuves kontroli un aktīvu pārvaldību, kā arī Article 21(2)(j) daudzfaktoru autentifikāciju un drošu saziņu.

DORA ir piemērojama no 2025. gada 17. janvāra un darbojas kā nozarei specifiska darbības noturības noteikumu kopa aptvertajām finanšu vienībām. Articles 5 un 6 prasa pārvaldību un dokumentētu IKT risku pārvaldības ietvaru. Article 8 prasa identificēt IKT aktīvus, informācijas aktīvus, IKT atbalstītas uzņēmējdarbības funkcijas un atkarības. Article 9 prasa aizsardzības un preventīvos pasākumus, tostarp drošības politikas, procedūras, protokolus un rīkus IKT sistēmām, drošu datu pārsūtīšanu, piekļuves kontroli, spēcīgu autentifikāciju, kriptogrāfisko atslēgu aizsardzību, izmaiņu pārvaldību, ielāpu uzstādīšanu un atjauninājumus. Articles 10 līdz 14 paplašina modeli uz atklāšanu, reaģēšanu, atjaunošanu, rezerves kopijām, atjaunošanu no rezerves kopijām, mācīšanos un komunikāciju.

GDPR pievieno privātuma skatījumu. Articles 5 un 32 prasa integritāti, konfidencialitāti, apstrādes drošību un pārskatatbildību, izmantojot atbilstošus tehniskos un organizatoriskos pasākumus. Publiskas mākoņkrātuves, pārmērīgi eksponētas datubāzes, nedroši noklusējuma iestatījumi un pārmērīga administratora piekļuve nav tikai infrastruktūras vājās vietas. Tās var kļūt par personas datu aizsardzības prasību neizpildi.

Viena drošu pamatkonfigurāciju programma var atbalstīt visus trīs režīmus, neveidojot dublējošas pierādījumu plūsmas.

Clarysec pamatkonfigurāciju modelis: politika, procedūra un platformas pierādījumi

Clarysec drošu konfigurāciju uztver kā atkārtojamu kontroles sistēmu, nevis vienreizēju drošās konfigurēšanas projektu. Pamatkonfigurācijai jābūt autorizētai politikā, pārvērstai procedūrās, ieviestai ar tehniskajiem kontroles pasākumiem un pierādītai ar pierādījumiem.

Informācijas drošības politika nosaka šo prasību uzņēmuma līmenī:

“Organizācijai jāuztur minimālais kontroles pasākumu pamatlīmenis, kas atvasināts no ISO/IEC 27001 A pielikuma un, ja piemērojams, papildināts ar ISO/IEC 27002, NIST SP 800-53 un COBIT 2019 kontroles pasākumiem.”
No sadaļas “Risku apstrāde un izņēmumi”, politikas punkts 7.2.1.

Šis punkts novērš situāciju, kurā konfigurācijas drošā konfigurēšana kļūst par personīgu izvēļu kopumu. Tas minimālo kontroles pasākumu pamatlīmeni piesaista atzītiem ietvariem.

Mākoņvidēm Mākoņpakalpojumu izmantošanas politika prasību konkretizē:

“Visām mākoņvidēm jāatbilst dokumentētai pamatkonfigurācijai, ko apstiprinājis mākoņdrošības arhitekts.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.3.1.

Audita un atbilstības uzraudzības politika pēc tam pamatkonfigurāciju pārvērš uzraudzītā kontroles pasākumā:

“Jāievieš automatizēti rīki konfigurācijas atbilstības, ievainojamību pārvaldības, ielāpu statusa un priviliģētas piekļuves uzraudzībai.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.4.1.

Konfigurācija nav atdalāma arī no ievainojamību un ielāpu pārvaldības. Ievainojamību un ielāpu pārvaldības politika nosaka:

“Ievainojamību novēršanai jābūt saskaņotai ar pamatkonfigurāciju un sistēmu drošās konfigurēšanas standartiem.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.4.1.

Šis aspekts ir būtisks. Sistēma var būt ar uzstādītiem ielāpiem un joprojām nedroša, ja ir iespējots SMBv1, administratīvās saskarnes ir eksponētas, žurnalēšana ir atspējota vai saglabājas vāji autentifikācijas iestatījumi. Zenith Controls: Starpatbilstības ceļvedī konfigurācijas pārvaldība tiek aplūkota kā preventīvs kontroles pasākums, kas aizsargā konfidencialitāti, integritāti un pieejamību, ar operacionālu spēju drošā konfigurācijā. Zenith Controls arī skaidro atkarību starp konfigurācijas pārvaldību un ievainojamību pārvaldību:

“Ievainojamību pārvaldība ir atkarīga no zināmām konfigurācijām. Bez definētas pamatkonfigurācijas nav iespējams nodrošināt, ka ielāpi tiek piemēroti konsekventi.”

Šis ir pierādījumu stāsts, ko auditori un regulatori sagaida arvien biežāk: kontroles sistēma, nevis izolēti tehniski uzdevumi.

ISO/IEC 27001:2022 A.8.9 kartēšana uz atbalstošajiem kontroles pasākumiem

ISO/IEC 27001:2022 A pielikuma kontroles pasākums A.8.9 Konfigurācijas pārvaldība ir enkurs, taču to nevajadzētu uztvert kā nelielu atsevišķu dokumentu. Tas ir atkarīgs no plašākas kontroles pasākumu saimes.

Šī starpkontroļu saistība ir iemesls, kāpēc Clarysec iesaka pārvaldīt drošu konfigurāciju kā ISMS spēju ar īpašniekiem, pierādījumiem, rādītājiem un ziņošanu vadībai.

Plašāka savstarpējā kartēšana palīdz to pašu pamatkonfigurāciju programmu pārtulkot citos ietvaros.

Praktiska pamatkonfigurācijas struktūra, ko var ieviest šomēnes

Visbiežākā kļūda ir mēģinājums uzrakstīt ideālu 80 lappušu drošās konfigurēšanas standartu, pirms kaut kas tiek piemērots. Sāciet ar minimālu, bet auditējamu pamatkonfigurāciju katrai būtiskajai tehnoloģiju saimei un pēc tam paaugstiniet tās briedumu ar automatizāciju un pārskatīšanu.

Mākoņkrātuves pamatkonfigurācijas pirmā versija var ietvert pēc noklusējuma atspējotu publisko piekļuvi, iespējotu šifrēšanu glabāšanā, iespējotu piekļuves žurnālu veidošanu, administratīvās piekļuves ierobežošanu apstiprinātām grupām, MFA prasību privileģētai konsoles piekļuvei, versiju pārvaldību, ja to prasa atjaunošanas prasības, replikācijas ierobežošanu apstiprinātos reģionos un izmaiņu veikšanu tikai ar apstiprinātiem infrastruktūras kā koda konveijeriem.

Windows Server 2022 pamatkonfigurācijas pirmā versija maksājumu apstrādes atbalstam var ietvert atspējotu SMBv1, atspējotus nebūtiskus pakalpojumus, RDP ierobežošanu uz droši konfigurētu starpniekserveri, Windows Defender Firewall ar noklusējuma lieguma noteikumiem, lokālo administratora kontu kontroli, notikumu žurnālu pārsūtīšanu uz SIEM, galapunktu aizsardzību un administratīvo izmaiņu sasaisti ar apstiprinātiem pieteikumiem.

Katrai pamatkonfigurācijai izveidojiet nelielu pierādījumu paketi:

1. Apstiprinātais pamatkonfigurācijas dokuments.
2. Ekrānuzņēmums vai eksportēta politika, kas parāda piemēroto konfigurāciju.
3. To aktīvu saraksts, uz kuriem attiecas pamatkonfigurācija.
4. Izmaiņu pieteikums, kas parāda, kā tiek apstiprināti atjauninājumi.
5. Konfigurācijas atbilstības pārskats vai manuālās pārskatīšanas ieraksts.

Tas tieši atbilst Zenith Blueprint posma “Kontroles pasākumi darbībā” 19. solim, kur Clarysec iesaka organizācijām izveidot konfigurācijas kontrolsarakstus būtiskajiem sistēmu tipiem, konsekventi piemērot iestatījumus piešķiršanas vai izvietošanas laikā, kur iespējams izmantojot automatizāciju, un pēc tam regulāri auditēt izvietotās sistēmas. Blueprint sniedz arī praktisku audita metodi:

“Izvēlieties dažas reprezentatīvas sistēmas (piemēram, vienu serveri, vienu komutatoru, vienu galalietotāja datoru) un validējiet, ka to konfigurācija atbilst jūsu drošajai pamatkonfigurācijai. Dokumentējiet atkāpes un trūkumu novēršanu.”

MVU gadījumā šī reprezentatīvās izlases pieeja bieži ir ātrākais ceļš no neformālas drošās konfigurēšanas uz auditam gataviem pierādījumiem.

MVU drošās konfigurēšanas piemēri, kas ātri samazina risku

Droša konfigurācija nav tikai uzņēmuma mākoņvides jautājums. MVU bieži panāk vislielāko riska samazinājumu ar dažiem skaidriem pamatkonfigurācijas noteikumiem.

Tīkla drošības politika — MVU nosaka:

“Publiskajam internetam drīkst eksponēt tikai būtiskus portus (piemēram, HTTPS, VPN); visi pārējie ir jāaizver vai jāfiltrē.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.3.

Tā prasa arī izmaiņu disciplīnu:

“Visām tīkla konfigurācijas izmaiņām (ugunsmūra noteikumiem, komutatoru ACL, maršrutēšanas tabulām) jāievēro dokumentēts izmaiņu pārvaldības process.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.9.1.

Un tā izveido pārskatīšanas regularitāti:

“Ārējam IT pakalpojumu sniedzējam jāveic ikgadēja ugunsmūra noteikumu, tīkla arhitektūras un bezvadu konfigurāciju pārskatīšana.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.6.1.

Galapunktu pamatkonfigurācijām nepieciešama tāda pati uzmanība. Clarysec Galapunktu aizsardzības pret ļaunatūru politika — MVU nosaka:

“Ierīcēm jāatspējo novecojuši protokoli (piemēram, SMBv1), kurus var izmantot ļaunatūra.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.2.1.3.

IoT un OT vidēs nedroši noklusējuma iestatījumi joprojām ir atkārtota eksponēšanas problēma. Lietu interneta (IoT) / operatīvo tehnoloģiju (OT) drošības politika — MVU nosaka:

“Noklusējuma vai cieti iekodētas paroles ir jānomaina pirms ierīču aktivizēšanas.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.2.

Šie politikas punkti nav abstrakti apgalvojumi. Tās ir pamatkonfigurācijas prasības, kuras var testēt, pierādīt un izsekot. MVU, kas gatavojas klientu sākotnējai izpētei, NIS2 piegādātāju pārskatīšanai, kiberdrošības apdrošināšanai vai ISO/IEC 27001:2022 sertifikācijai, tās rada tūlītēju vērtību.

Izņēmumu pārvaldība: kontroles pasākums, kas nošķir briedumu no dokumentācijas

Katrai pamatkonfigurācijai būs izņēmumi. Mantotai lietojumprogrammai var būt nepieciešams vecs protokols. Piegādātāja iekārta var neatbalstīt vēlamo šifrēšanas iestatījumu. Migrācijai var būt nepieciešama pagaidu ugunsmūra atvēršana. Jautājums nav par to, vai izņēmumi pastāv. Jautājums ir par to, vai tie tiek pārvaldīti.

Nobriedis izņēmuma ieraksts ietver:

• Pamatkonfigurācijas prasību, kas tiek pārkāpta.
• Biznesa pamatojumu.
• Ietekmēto aktīvu un īpašnieku.
• Risku izvērtēšanu.
• Kompensējošos kontroles pasākumus.
• Apstiprināšanas pilnvaru.
• Beigu datumu.
• Uzraudzības prasību.
• Trūkumu novēršanas plānu.

Šeit ISO/IEC 27001:2022 riska apstrāde un DORA samērīgums darbojas kopā. ISO/IEC 27001:2022 prasa pamatot kontroles lēmumus ar risku izvērtēšanu, riska apstrādi, Piemērojamības paziņojumu un riska īpašnieka apstiprinājumu. DORA ļauj samērīgu ieviešanu, ņemot vērā lielumu, riska profilu un pakalpojumu būtību, mērogu un sarežģītību, tomēr joprojām sagaida dokumentētu IKT risku pārvaldību, uzraudzību, nepārtrauktību, testēšanu un informētību.

Samērīgums nav atļauja izlaist pamatkonfigurācijas. Tā ir prasība tās mērogot saprātīgi.

Mikro vai mazākai finanšu vienībai saskaņā ar vienkāršotu IKT risku ietvaru pamatkonfigurācija var būt kodolīga un atbalstīta ar manuālu izlasi. Lielākai finanšu vienībai tai pašai jomai, visticamāk, būs nepieciešamas automatizētas konfigurācijas pārbaudes, iekšējā audita iesaiste, ikgadēja testēšana un ziņošana vadības struktūrai.

Izmaiņu pārvaldības politika arī atgādina organizācijām uzraudzīt:

“Konfigurācijas novirzi vai manipulācijas pēc apstiprinātām izmaiņām.”
No sadaļas “Ievērošana un atbilstība”, politikas punkts 8.1.2.3.

Šī frāze sasaista izmaiņu kontroli ar noviržu atklāšanu. Izmaiņa var būt apstiprināta un tomēr radīt risku, ja ieviestais stāvoklis atšķiras no apstiprinātā stāvokļa vai ja pagaidu iestatījums paliek spēkā pēc izmaiņu loga beigām.

Vienas pierādījumu pēdas izveide daudziem atbilstības pienākumiem

Drošai pamatkonfigurācijai nevajadzētu radīt piecas atsevišķas atbilstības darba plūsmas. Clarysec modelis izmanto vienu pierādījumu pēdu, kas kartēta uz vairākiem pienākumiem.

Galvenais ir izsekojamība. Zenith Blueprint audita, pārskatīšanas un uzlabošanas posma 24. solī organizācijām liek atjaunināt Piemērojamības paziņojumu un krusteniski pārbaudīt to ar risku apstrādes plānu. Ja kontroles pasākums ir piemērojams, nepieciešams pamatojums. Šim pamatojumam jābūt saistītam ar risku, juridisku pienākumu, līgumisku prasību vai biznesa vajadzību.

Drošas konfigurācijas gadījumā SoA ierakstam par A.8.9 jāatsaucas uz drošas pamatkonfigurācijas standartu, aptvertajām aktīvu kategorijām, pamatkonfigurāciju īpašniekiem, izmaiņu pārvaldības procedūru, uzraudzības metodi, izņēmumu procesu, pārskatīšanas regularitāti un starpatbilstības pienākumiem, piemēram, NIS2 Article 21, DORA Articles 6, 8 un 9, GDPR Article 32 un klientu saistībām.

Kā auditori testēs drošas pamatkonfigurācijas

Droša konfigurācija auditoriem ir pievilcīga, jo tā ir bagāta ar pierādījumiem. To var testēt ar dokumentiem, intervijām, izlasi un tehnisko pārbaudi.

Praktiskie jautājumi ir paredzami:

• Vai jaunu serveru uzstādīšanā izmantojat drošās konfigurēšanas kontrolsarakstu?
• Kā jūs novēršat tādu nedrošu pakalpojumu kā Telnet darbību maršrutētājos?
• Vai mākoņkrātuves resursi pēc noklusējuma ir privāti?
• Kurš var apstiprināt atkāpi no pamatkonfigurācijas?
• Kā pēc izmaiņas atklājat konfigurācijas novirzi?
• Vai varat parādīt nesenu konfigurācijas pārskatīšanu?
• Vai varat parādīt, ka konstatētā atkāpe tika novērsta?
• Vai tīkla un mākoņvides konfigurācijas tiek dublētas un pārvaldītas ar versiju kontroli?
• Vai izmaiņu atcelšanas procedūras ir dokumentētas un testētas?

Spēcīgākās organizācijas uztur pamatkonfigurācijas pierādījumu paketi katrai būtiskajai sistēmu kategorijai. Tā saīsina auditus, uzlabo atbildes klientu sākotnējās izpētes procesā un palīdz vadībai izprast faktisko kontroles veiktspēju.

Pārvērtiet konfigurācijas novirzi par valdes līmeņa kiberdrošības higiēnas rādītāju

Valdēm nav jāredz katrs ugunsmūra noteikums. Tām ir jāzina, vai kiberdrošības higiēna uzlabojas vai pasliktinās.

Noderīgs drošas konfigurācijas informācijas panelis ietver:

• To aktīvu īpatsvaru, kas kartēti uz apstiprinātu pamatkonfigurāciju.
• To aktīvu īpatsvaru, kas iztur pamatkonfigurācijas pārbaudes.
• Kritisko pamatkonfigurācijas atkāpju skaitu.
• Atvērto atkāpju vidējo vecumu.
• Beigušos izņēmumu skaitu.
• Atklāto nesankcionēto konfigurācijas izmaiņu skaitu.
• Privileģēto konfigurācijas izmaiņu īpatsvaru ar apstiprinātiem pieteikumiem.
• Publiskās mākoņvides eksponēšanas izņēmumus.
• Pamatkonfigurāciju pārskatīšanas statusu pa tehnoloģiju saimēm.

Šie rādītāji atbalsta ISO/IEC 27001:2022 veiktspējas izvērtēšanu, NIS2 vadības pārraudzību un DORA IKT riska ziņošanu. Tie arī dabiski kartējas uz NIST CSF 2.0 pārvaldības rezultātiem un COBIT 2019 uzraudzības un atbilstības mērķiem.

Vienkāršs augstākās vadības noteikums palīdz: neviena kritiskā sistēma netiek nodota ražošanas vidē bez pamatkonfigurācijas pierādījumiem. To var piemērot ar izmaiņu pārvaldību, CI/CD vārtiem, mākoņpolitiku pārbaudēm, infrastruktūras kā koda pārskatīšanu, MDM atbilstību, GPO piemērošanu vai tīkla konfigurācijas pārskatīšanu. Brieduma līmenis var atšķirties, taču kontroles loģikai nevajadzētu mainīties.

90 dienu drošas pamatkonfigurācijas rokasgrāmata

Ja sākat no nulles, nemēģiniet atrisināt visas konfigurācijas problēmas vienlaikus. Izmantojiet 90 dienu plānu.

1.–30. diena: definējiet minimālo pamatkonfigurāciju

Identificējiet kritiskās aktīvu kategorijas. Katrai piešķiriet tehnisko īpašnieku, riska īpašnieku un apstiprināšanas pilnvaru. Izveidojiet pirmo pamatkonfigurāciju iestatījumiem, kas visvairāk saistīti ar noturību pret izspiedējprogrammatūru, mākoņvides eksponēšanu, priviliģētu piekļuvi, žurnalēšanu, šifrēšanu un datu aizsardzību.

Izveidojiet pamatkonfigurāciju reģistru un kartējiet to uz ISMS darbības jomu, risku reģistru un Piemērojamības paziņojumu. Ja uz jums attiecas NIS2, noskaidrojiet, vai esat būtiska vai svarīga vienība, vai arī klienti sagaida NIS2 saskaņotu kiberdrošības higiēnu. Ja esat finanšu vienība DORA darbības jomā, identificējiet, kuri IKT aktīvi atbalsta kritiskas vai svarīgas funkcijas. Ja apstrādājat personas datus, kartējiet sistēmas uz GDPR apstrādes darbībām un datu kategorijām.

31.–60. diena: piemērojiet un savāciet pierādījumus

Piemērojiet pamatkonfigurāciju augsta riska sistēmu izlasei. Izmantojiet automatizāciju, kur tas iespējams, taču negaidiet ideālus rīkus. Eksportējiet konfigurācijas, fiksējiet ekrānuzņēmumus, saglabājiet politikas iestatījumus un reģistrējiet izmaiņu pieteikumus.

Katram izņēmumam izveidojiet riska ierakstu ar beigu datumu. Katrai atkāpei izveidojiet trūkumu novēršanas pieteikumu.

61.–90. diena: uzraugiet, ziņojiet un uzlabojiet

Veiciet konfigurācijas pārskatīšanu. Izvēlieties izlasei vienu serveri, vienu galapunktu, vienu tīkla ierīci un vienu mākoņvidi. Salīdziniet faktiskos iestatījumus ar apstiprināto pamatkonfigurāciju. Dokumentējiet atkāpes un korektīvās darbības.

Ziņojiet vadībai par pamatkonfigurācijas atbilstību. Atjauniniet Piemērojamības paziņojumu un risku apstrādes plānu. Atkārtotas atkāpes nododiet pamatcēloņa analīzei. Ja nepareiza konfigurācija izraisīja incidentu vai veicināja to, atjauniniet attiecīgo pamatkonfigurāciju kā daļu no gūtajām mācībām.

Tas dod auditoriem kaut ko testējamu, regulatoriem kaut ko saprotamu un vadībai kaut ko pārvaldāmu.

Noslēguma doma: droša konfigurācija ir kiberdrošības higiēna ar pierādījumiem

NIS2 izmanto kiberdrošības risku pārvaldības pasākumu un pamata kiberdrošības higiēnas valodu. DORA izmanto IKT riska, noturības, uzraudzības, nepārtrauktības un testēšanas valodu. GDPR izmanto atbilstošu pasākumu un pārskatatbildības valodu. ISO/IEC 27001:2022 izmanto riska apstrādes, kontroles pasākumu, dokumentētas informācijas, veiktspējas izvērtēšanas un nepārtrauktas pilnveides valodu.

Drošas pamatkonfigurācijas tās visas savieno.

Tās parāda, ka sistēmas netiek izvietotas ar nedrošiem noklusējuma iestatījumiem. Tās parāda, ka izmaiņas tiek kontrolētas. Tās parāda, ka konfigurācijas novirze tiek atklāta. Tās parāda, ka izņēmumi tiek pieņemti, balstoties uz risku. Tās parāda, ka pierādījumi pastāv pirms auditors tos pieprasa.

Vissvarīgāk — tās samazina reālu operacionālo risku. Piektdienas pēcpusdienas ugunsmūra noteikums, publiska mākoņkrātuve, aizmirsts SMBv1 iestatījums, noklusējuma IoT parole un nežurnalēta administratora konsole nav teorētiski audita konstatējumi. Tie ir praktiski atteices punkti.

Clarysec palīdz organizācijām pārvērst šos atteices punktus kontrolētās, uzraudzītās un auditējamās pamatkonfigurācijās.

Nākamie soļi

Ja jūsu organizācijai ir jāpierāda droša konfigurācija ISO/IEC 27001:2022, NIS2 kiberdrošības higiēnas, DORA IKT risku pārvaldības, GDPR pārskatatbildības vai klientu apliecinājuma vajadzībām, sāciet ar Clarysec rīkkopu:

• Izmantojiet Zenith Blueprint: Auditora 30 soļu ceļkarte, lai ieviestu konfigurācijas pārvaldību posmā “Kontroles pasākumi darbībā”, 19. solī, un validētu to audita, pārskatīšanas un uzlabošanas posmā, 24. solī.
• Izmantojiet Zenith Controls: Starpatbilstības ceļvedis, lai kartētu konfigurācijas pārvaldību uz atbalstošajiem ISO/IEC 27001:2022 kontroles pasākumiem, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 un audita metodoloģijām.
• Izmantojiet Clarysec politikas, piemēram, Informācijas drošības politika, Mākoņpakalpojumu izmantošanas politika, Audita un atbilstības uzraudzības politika, Ievainojamību un ielāpu pārvaldības politika, Tīkla drošības politika — MVU, Galapunktu aizsardzības pret ļaunatūru politika — MVU un Lietu interneta (IoT) / operatīvo tehnoloģiju (OT) drošības politika — MVU, lai definētu, piemērotu un pierādītu savas pamatkonfigurācijas prasības.

Droša pamatkonfigurācija nav tikai drošās konfigurēšanas kontrolsaraksts. Tā ir pierādījums, ka organizācija zina, kā izskatās drošs stāvoklis, to konsekventi piemēro un spēj to pierādīt brīdī, kad tas ir svarīgi.