Saugios konfigūracijos baziniai standartai NIS2 ir DORA kontekste

Penktadienio popietės klaidinga konfigūracija, tapusi valdybos problema

Penktadienį 16:40 finansinių technologijų platformos inžinerijos vadovas patvirtino iš pažiūros įprastą ugniasienės pakeitimą. Integracijai su mokėjimų analitikos teikėju patikrinti buvo laikinai atidaryta taisyklė. Užklausoje buvo įrašyta: „pašalinti po testavimo“. Testas pavyko. Taisyklė liko.

Po trijų savaičių išorinis skenavimas parodė, kad administravimo sąsaja pasiekiama iš interneto. Serveriui buvo įdiegtos pataisos. Įprastiems naudotojams buvo taikomas MFA. Pažeidžiamumų skeneris nepažymėjo kritinio CVE. Tačiau sistema vis tiek nebuvo saugi, nes jos konfigūracija nukrypo nuo organizacijos patvirtintos sustiprintos būsenos.

Pirmadienio rytą CISO vienu metu vyko keturi pokalbiai:

1. Reguliuotojas norėjo sužinoti, ar buvo paveiktas operacinis atsparumas.
2. Duomenų apsaugos pareigūnas (DAP) norėjo sužinoti, ar galėjo būti atskleisti asmens duomenys.
3. Valdyba norėjo suprasti, kodėl „laikini“ pakeitimai nebuvo aptinkami.
4. ISO/IEC 27001:2022 vidaus auditorius prašė įrodymų, kad saugios bazinės konfigūracijos buvo apibrėžtos, patvirtintos, įgyvendintos ir stebimos.

Būtent čia daugelis saugumo programų susiduria su nepatogia tiesa. Saugus konfigūravimas nėra vien techninis saugumo stiprinimo kontrolinis sąrašas. 2026 m. saugios konfigūracijos baziniai standartai yra valdysenos, kibernetinės higienos, IRT rizikos, audito įrodymų ir valdybos atskaitomybės klausimas.

Kita tos pačios problemos versija kartojasi daugelyje reguliuojamų organizacijų. Maria, augančio B2B mokėjimų tvarkytojo CISO, turi stiprius inžinierius, sistemas su įdiegtomis pataisomis ir debesijos gerąsias praktikas. Tačiau pasirengimo NIS2 ir DORA vertinimas išryškina vieną kritinę išvadą: trūksta formalizuotų saugios konfigūracijos bazinių standartų. Jos komanda žino, kaip sustiprinti serverių saugumą, tačiau didelė šių žinių dalis yra inžinierių galvose, o ne patvirtintuose standartuose, automatizuotose patikrose ar įrodymų rinkiniuose.

Ši spraga nebėra pateisinama. NIS2 reikalauja, kad valdymo organai patvirtintų ir prižiūrėtų kibernetinio saugumo rizikos valdymo priemones. DORA reikalauja dokumentuotos IRT rizikos valdymo sistemos ir atsparių IRT operacijų. GDPR reikalauja tinkamų techninių ir organizacinių priemonių. ISO/IEC 27001:2022 reikalauja rizika grindžiamo kontrolės priemonių parinkimo, įgyvendinimo, stebėsenos, audito ir nuolatinio tobulinimo.

Saugios konfigūracijos baziniai standartai sujungia visas šias pareigas į vieną praktinę kontrolės sistemą: apibrėžti bazinę konfigūraciją, priskirti atsakomybę, taikyti ją suteikiant prieigą ir diegiant sistemas, valdyti išimtis, aptikti nuokrypius, pagrįsti įrodymais ir tobulinti po auditų ar incidentų.

Kaip Clarysec Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plane nurodoma etape „Kontrolės priemonės praktikoje“, 19 žingsnyje „Technologinės kontrolės priemonės I“:

„Daugelis pažeidimų kyla ne dėl programinės įrangos trūkumų, o dėl netinkamų konfigūracijos sprendimų. Nepakeisti numatytieji slaptažodžiai, įjungtos nesaugios paslaugos, atviri nereikalingi prievadai arba sistemos, be pagrindimo pasiekiamos iš interneto.“

Šis sakinys paaiškina, kodėl saugios konfigūracijos baziniai standartai dabar yra pagrindinė atsparumo kontrolės priemonė. Jie apibrėžia, ką reiškia „saugu“, dar prieš to paklausiant auditoriui, reguliuotojui, klientui ar užpuolikui.

Kas iš tikrųjų yra saugios konfigūracijos bazinis standartas

Saugios konfigūracijos bazinis standartas yra patvirtintas, dokumentuotas ir pakartojamas saugumo nustatymų rinkinys konkrečiam sistemos tipui. Jis gali būti taikomas Windows serveriams, Linux pagrindiniams kompiuteriams, tinklo įrenginiams, SaaS nuomininkams, debesijos saugykloms, Kubernetes klasteriams, duomenų bazėms, ugniasienėms, galiniams įrenginiams, tapatybės platformoms, IoT įrenginiams ir operacinėms technologijoms.

Stiprus bazinis standartas atsako į praktinius klausimus:

• Kurios paslaugos pagal numatytuosius nustatymus yra išjungtos?
• Kurie prievadai gali būti pasiekiami iš išorės?
• Kurie autentifikavimo ir MFA nustatymai yra privalomi?
• Kurie žurnalavimo nustatymai turi būti įjungti?
• Kurie šifravimo nustatymai yra būtini?
• Kurios administravimo sąsajos yra apribotos?
• Kurie debesijos ištekliai gali būti vieši ir kieno patvirtinimu?
• Kuriems nuokrypiams būtinas rizikos priėmimas?
• Kaip dažnai tikriname konfigūracijos nuokrypius?
• Kokie įrodymai patvirtina, kad bazinė konfigūracija veikia?

Dažniausia klaida – bazinius standartus laikyti inžinerinėmis nuostatomis, o ne valdomomis kontrolės priemonėmis. Linux administratoriaus kontrolinis sąrašas, debesijos architekto wiki puslapis ir tinklo inžinieriaus ugniasienės taisyklių praktika gali būti naudingi, tačiau auditui tinkami jie tampa tik tada, kai yra patvirtinti, susieti su rizika, nuosekliai taikomi ir stebimi.

Todėl ISO/IEC 27001:2022 yra toks naudingas atskaitos taškas. 4.1–4.3 punktai reikalauja, kad organizacijos suprastų vidaus ir išorės veiksnius, suinteresuotąsias šalis ir ISVS taikymo sritį, įskaitant teisinius, reguliavimo, sutartinius ir trečiųjų šalių reikalavimus. 6.1.2 ir 6.1.3 punktai reikalauja informacijos saugos rizikos vertinimo, rizikos tvarkymo, kontrolės priemonių parinkimo, taikytinumo pareiškimo ir rizikos savininko patvirtinimo. 8.2 ir 8.3 punktai reikalauja rizikos vertinimus ir rizikos tvarkymą kartoti planuotais intervalais arba po reikšmingų pakeitimų.

A priedas techninį lūkestį sukonkretina per A.8.9 „Konfigūracijų valdymas“, kurį palaiko turto inventorizavimas, pažeidžiamumų valdymas, pakeitimų valdymas, žurnalavimas, stebėsena, prieigos kontrolė, kriptografija, debesijos paslaugų naudojimas ir dokumentuotos veiklos procedūros.

Rezultatas – paprastas, bet stiprus valdysenos teiginys: jei organizacija negali parodyti, ką reiškia saugi būsena kiekvienam pagrindiniam sistemos tipui, ji negali įtikinamai pagrįsti kibernetinės higienos pagal NIS2, IRT rizikos kontrolės pagal DORA, atskaitomybės pagal GDPR ar kontrolės veiksmingumo pagal ISO/IEC 27001:2022.

Kodėl NIS2, DORA ir GDPR bazines konfigūracijas daro neišvengiamas

NIS2, DORA ir GDPR vartoja skirtingą terminiją, tačiau sueina į tą patį operacinį reikalavimą: sistemos turi būti saugiai sukonfigūruotos, nuolat stebimos ir valdomos per atskaitingą rizikos valdymą.

NIS2 Article 20 reikalauja, kad esminių ir svarbių subjektų valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir gautų kibernetinio saugumo mokymus. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių. Saugios konfigūracijos baziniai standartai palaiko Article 21(2)(a) rizikos analizės ir informacinių sistemų saugumo politikas, Article 21(2)(e) tinklų ir informacinių sistemų įsigijimo, kūrimo ir priežiūros saugumą, įskaitant pažeidžiamumų tvarkymą, Article 21(2)(f) veiksmingumo vertinimo politikas ir procedūras, Article 21(2)(g) bazinę kibernetinę higieną ir kibernetinio saugumo mokymus, Article 21(2)(h) kriptografiją, Article 21(2)(i) prieigos kontrolę ir turto valdymą bei Article 21(2)(j) daugiaveiksnį autentifikavimą ir saugią komunikaciją.

DORA taikoma nuo 2025 m. sausio 17 d. ir veikia kaip sektoriui skirta operacinio atsparumo taisyklių sistema taikomiems finansų subjektams. Articles 5 ir 6 reikalauja valdysenos ir dokumentuotos IRT rizikos valdymo sistemos. Article 8 reikalauja identifikuoti IRT turtą, informacijos išteklius, IRT palaikomas verslo funkcijas ir priklausomybes. Article 9 reikalauja apsaugos ir prevencijos priemonių, įskaitant IRT sistemų saugumo politikas, procedūras, protokolus ir priemones, saugų duomenų perdavimą, prieigos kontrolę, stiprų autentifikavimą, kriptografinių raktų apsaugą, pakeitimų valdymą, pataisų diegimą ir atnaujinimus. Articles 10–14 išplečia šį modelį į aptikimą, reagavimą, atkūrimą, atsarginių kopijų kūrimą, atstatymą, mokymąsi ir komunikaciją.

GDPR prideda privatumo perspektyvą. Articles 5 ir 32 reikalauja vientisumo, konfidencialumo, tvarkymo saugumo ir atskaitomybės taikant tinkamas technines ir organizacines priemones. Vieši debesijos saugyklų segmentai, pernelyg atviros duomenų bazės, nesaugūs numatytieji nustatymai ir perteklinė administratoriaus lygmens prieiga nėra tik infrastruktūros silpnybės. Jie gali tapti asmens duomenų apsaugos nesėkmėmis.

Viena saugios konfigūracijos bazinių standartų programa gali palaikyti visas tris reguliavimo sistemas nekurdama dubliuojančių įrodymų srautų.

Clarysec bazinių standartų modelis: politika, procedūra ir platformos įrodymai

Clarysec saugų konfigūravimą laiko pakartojama kontrolės sistema, o ne vienkartiniu saugumo stiprinimo projektu. Bazinė konfigūracija turi būti įgaliota politika, perkelta į procedūras, įgyvendinta techninėmis kontrolės priemonėmis ir pagrįsta įrodymais.

Informacijos saugumo politika šį lūkestį nustato organizacijos lygmeniu:

„Organizacija turi palaikyti minimalų kontrolės priemonių bazinį rinkinį, išvestą iš ISO/IEC 27001 A priedo ir, kai tinkama, papildytą ISO/IEC 27002, NIST SP 800-53 ir COBIT 2019 kontrolės priemonėmis.“
Iš skyriaus „Rizikos tvarkymas ir išimtys“, politikos 7.2.1 punktas.

Ši nuostata neleidžia konfigūracijos stiprinimui virsti asmeninių nuostatų rinkiniu. Ji įtvirtina minimalų kontrolės priemonių bazinį rinkinį pripažintose sistemose.

Debesijos aplinkoms Debesijos paslaugų naudojimo politika reikalavimą sukonkretina:

„Visos debesijos aplinkos turi atitikti dokumentuotą bazinę konfigūraciją, patvirtintą debesijos saugumo architekto.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.3.1 punktas.

Audito ir atitikties stebėsenos politika tada paverčia bazinę konfigūraciją stebima kontrolės priemone:

„Automatizuotos priemonės turi būti įdiegtos konfigūracijos atitikčiai, pažeidžiamumų valdymui, pataisų būsenai ir privilegijuotai prieigai stebėti.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.4.1 punktas.

Konfigūracija taip pat neatsiejama nuo pažeidžiamumų ir pataisų valdymo. Pažeidžiamumų ir pataisų valdymo politika nustato:

„Pažeidžiamumų šalinimas turi būti suderintas su bazine konfigūracija ir sistemų saugumo stiprinimo standartais.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.4.1 punktas.

Ši nuostata svarbi. Sistema gali būti su įdiegtomis pataisomis ir vis tiek išlikti nesaugi, jei įjungtas SMBv1, administravimo sąsajos yra atviros, žurnalavimas išjungtas arba palikti silpni autentifikavimo nustatymai. Zenith Controls: kelių atitikties sričių vadove konfigūracijų valdymas laikomas prevencine kontrolės priemone, saugančia konfidencialumą, vientisumą ir prieinamumą, turinčia operacinį gebėjimą saugiai konfigūruoti. Zenith Controls taip pat paaiškina konfigūracijų valdymo ir pažeidžiamumų valdymo priklausomybę:

„Pažeidžiamumų valdymas priklauso nuo žinomų konfigūracijų. Be apibrėžtos bazinės konfigūracijos neįmanoma užtikrinti, kad pataisos būtų taikomos nuosekliai.“

Tai yra įrodymų logika, kurios auditoriai ir reguliuotojai vis dažniau tikisi: kontrolės sistema, o ne pavienės techninės užduotys.

ISO/IEC 27001:2022 A.8.9 susiejimas su palaikančiomis kontrolės priemonėmis

ISO/IEC 27001:2022 A priedo kontrolės priemonė A.8.9 „Konfigūracijų valdymas“ yra pagrindas, tačiau jos nereikėtų laikyti mažu savarankišku dokumentu. Ji priklauso nuo platesnės kontrolės priemonių šeimos.

Šis kontrolės priemonių tarpusavio ryšys paaiškina, kodėl Clarysec rekomenduoja saugų konfigūravimą valdyti kaip ISVS gebėjimą su savininkais, įrodymais, rodikliais ir ataskaitomis vadovybei.

Platesnis susiejimas padeda tą pačią bazinių standartų programą perkelti į kitas sistemas.

Praktinė bazinių standartų struktūra, kurią galite įgyvendinti šį mėnesį

Dažniausia klaida – bandyti parašyti idealų 80 puslapių saugumo stiprinimo standartą prieš pradedant ką nors taikyti. Pradėkite nuo minimalaus, bet auditui tinkamo bazinio standarto kiekvienai pagrindinei technologijų šeimai, o vėliau brandinkite jį automatizavimu ir peržiūromis.

Debesijos saugyklos bazinės konfigūracijos pirmoji versija gali apimti pagal numatytuosius nustatymus išjungtą viešą prieigą, įjungtą saugomų duomenų šifravimą, įjungtą prieigos žurnalų vedimą, administratoriaus lygmens prieigą tik patvirtintoms grupėms, privalomą MFA privilegijuotai prieigai prie konsolės, versijavimą ten, kur to reikalauja atkūrimo reikalavimai, replikaciją tik į patvirtintus regionus ir pakeitimus tik per patvirtintus infrastruktūros kaip kodo konvejerius.

Windows Server 2022 bazinė konfigūracija, palaikanti mokėjimų tvarkymą, pirmojoje versijoje gali apimti išjungtą SMBv1, išjungtas neesmines paslaugas, RDP apribojimą iki sustiprinto tarpinio prieigos serverio, įjungtą Windows Defender Firewall su „numatytai draudžiama“ taisyklėmis, kontroliuojamas vietinio administratoriaus paskyras, į SIEM persiunčiamus įvykių žurnalus, įjungtą galinių įrenginių apsaugą ir administracinius pakeitimus, susietus su patvirtintomis užklausomis.

Kiekvienai bazinei konfigūracijai parenkite nedidelį įrodymų rinkinį:

1. Patvirtintą bazinės konfigūracijos dokumentą.
2. Ekrano kopiją arba eksportuotą politiką, rodančią pritaikytą konfigūraciją.
3. Turto, kuriam taikoma bazinė konfigūracija, sąrašą.
4. Pakeitimo užklausą, rodančią, kaip tvirtinami atnaujinimai.
5. Konfigūracijos atitikties ataskaitą arba rankinės peržiūros įrašą.

Tai tiesiogiai atitinka Zenith Blueprint etapą „Kontrolės priemonės praktikoje“, 19 žingsnį, kuriame Clarysec rekomenduoja organizacijoms nustatyti konfigūracijos kontrolinius sąrašus pagrindiniams sistemų tipams, nuosekliai taikyti nustatymus suteikiant prieigą ir diegiant sistemas, kai įmanoma – automatizuotai, ir reguliariai audituoti įdiegtas sistemas. Blueprint taip pat pateikia praktinį audito metodą:

„Pasirinkite kelias reprezentatyvias sistemas (pvz., vieną serverį, vieną komutatorių, vieną galutinio naudotojo kompiuterį) ir patikrinkite, ar jų konfigūracija atitinka jūsų saugią bazinę konfigūraciją. Dokumentuokite nukrypimus ir taisomuosius veiksmus.“

MVĮ toks reprezentatyvios imties metodas dažnai yra greičiausias kelias nuo neformalaus saugumo stiprinimo iki auditui tinkamų įrodymų.

MVĮ saugumo stiprinimo pavyzdžiai, greitai mažinantys riziką

Saugus konfigūravimas nėra vien didelių įmonių debesijos klausimas. MVĮ dažnai didžiausią rizikos sumažėjimą pasiekia taikydamos kelias aiškias bazines taisykles.

Tinklo saugumo politika – MVĮ nustato:

„Viešajame internete gali būti pasiekiami tik būtini prievadai (pvz., HTTPS, VPN); visi kiti turi būti uždaryti arba filtruojami.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.1.3 punktas.

Ji taip pat reikalauja pakeitimų drausmės:

„Visi tinklo konfigūracijų pakeitimai (ugniasienės taisyklės, komutatorių ACL, maršruto lentelės) turi būti atliekami pagal dokumentuotą pakeitimų valdymo procesą.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.9.1 punktas.

Ir nustato peržiūros periodiškumą:

„IT pagalbos teikėjas turi kasmet atlikti ugniasienės taisyklių, tinklo architektūros ir belaidžio ryšio konfigūracijų peržiūrą.“
Iš skyriaus „Valdysenos reikalavimai“, politikos 5.6.1 punktas.

Galinių įrenginių bazinės konfigūracijos reikalauja tokio pat dėmesio. Clarysec Galinių įrenginių apsaugos ir apsaugos nuo kenkėjiškos programinės įrangos politika – MVĮ nustato:

„Įrenginiuose turi būti išjungti pasenę protokolai (pvz., SMBv1), kuriuos gali išnaudoti kenkimo programinė įranga.“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos 6.2.1.3 punktas.

IoT ir OT aplinkose nesaugūs numatytieji nustatymai išlieka pasikartojantis pažeidžiamumas. Daiktų interneto (IoT) / operacinių technologijų (OT) saugumo politika – MVĮ nustato:

„Numatytieji ar kietai užkoduoti slaptažodžiai turi būti pakeisti prieš aktyvuojant įrenginius.“
Iš skyriaus „Valdysenos reikalavimai“, politikos 5.3.2 punktas.

Šios politikų nuostatos nėra abstraktūs teiginiai. Tai baziniai reikalavimai, kuriuos galima testuoti, pagrįsti įrodymais ir sekti. MVĮ, besirengiančiai klientų deramam patikrinimui, NIS2 tiekėjų peržiūroms, kibernetiniam draudimui ar ISO/IEC 27001:2022 sertifikavimui, jie sukuria tiesioginę vertę.

Išimčių valdymas: kontrolė, skirianti brandą nuo formalumo

Kiekviena bazinė konfigūracija turės išimčių. Senoji taikomoji programa gali reikalauti seno protokolo. Tiekėjo įrenginys gali nepalaikyti pageidaujamo šifravimo nustatymo. Migracijai gali prireikti laikino ugniasienės atidarymo. Klausimas nėra, ar išimtys egzistuoja. Klausimas – ar jos valdomos.

Brandus išimties įrašas apima:

• Pažeidžiamą bazinį reikalavimą.
• Verslo pagrindimą.
• Paveiktą turtą ir savininką.
• Rizikos vertinimą.
• Kompensuojančias kontrolės priemones.
• Tvirtinimo įgaliojimus.
• Galiojimo pabaigos datą.
• Stebėsenos reikalavimą.
• Taisomųjų veiksmų planą.

Čia ISO/IEC 27001:2022 rizikos tvarkymas ir DORA proporcingumas veikia kartu. ISO/IEC 27001:2022 reikalauja kontrolės sprendimus pagrįsti rizikos vertinimu, rizikos tvarkymu, taikytinumo pareiškimu ir rizikos savininko patvirtinimu. DORA leidžia proporcingą įgyvendinimą pagal dydį, rizikos profilį ir paslaugų pobūdį, mastą bei sudėtingumą, tačiau vis tiek tikisi dokumentuotos IRT rizikos valdysenos, stebėsenos, tęstinumo, testavimo ir informuotumo.

Proporcingumas nėra leidimas praleisti bazinius standartus. Tai reikalavimas juos protingai pritaikyti mastui.

Mikro ar mažesniam finansų subjektui, taikančiam supaprastintą IRT rizikos sistemą, baziniai standartai gali būti glausti ir palaikomi rankine imties patikra. Didesniam finansų subjektui ta pati sritis greičiausiai reikalaus automatizuotų konfigūracijos patikrų, vidaus audito įsitraukimo, kasmetinio testavimo ir ataskaitų valdymo organui.

Pakeitimų valdymo politika taip pat primena organizacijoms stebėti:

„Konfigūracijos nuokrypį arba klastojimą po patvirtintų pakeitimų“
Iš skyriaus „Įgyvendinimas ir atitiktis“, politikos 8.1.2.3 punktas.

Ši formuluotė susieja pakeitimų kontrolę su nuokrypių aptikimu. Pakeitimas gali būti patvirtintas ir vis tiek sukurti riziką, jei įgyvendinta būsena skiriasi nuo patvirtintos būsenos arba jei laikinas nustatymas lieka pasibaigus pakeitimo langui.

Vieno įrodymų pėdsako kūrimas kelioms atitikties pareigoms

Saugios konfigūracijos baziniai standartai neturėtų sukurti penkių atskirų atitikties darbo srautų. Clarysec modelis naudoja vieną įrodymų pėdsaką, susietą su keliomis pareigomis.

Svarbiausia yra atsekamumas. Zenith Blueprint audito, peržiūros ir tobulinimo etapo 24 žingsnis nurodo organizacijoms atnaujinti taikytinumo pareiškimą ir kryžmiškai patikrinti jį su rizikos tvarkymo planu. Jei kontrolės priemonė taikytina, reikia pagrindimo. Šis pagrindimas turi būti susietas su rizika, teisine prievole, sutartiniu reikalavimu arba verslo poreikiu.

Saugaus konfigūravimo atveju SoA įrašas dėl A.8.9 turėtų nurodyti saugios konfigūracijos bazinį standartą, taikomas turto kategorijas, bazinių standartų savininkus, pakeitimų valdymo procedūrą, stebėsenos metodą, išimčių procesą, peržiūros periodiškumą ir kelių atitikties sričių pareigas, pavyzdžiui, NIS2 Article 21, DORA Articles 6, 8 ir 9, GDPR Article 32 ir klientų įsipareigojimus.

Kaip auditoriai testuos saugios konfigūracijos bazinius standartus

Saugus konfigūravimas auditoriams patrauklus, nes turi daug įrodymų. Jis gali būti testuojamas per dokumentus, interviu, imtis ir techninę patikrą.

Praktiniai klausimai yra nuspėjami:

• Ar diegdami naujus serverius naudojate saugumo stiprinimo kontrolinį sąrašą?
• Kaip neleidžiate nesaugioms paslaugoms, pavyzdžiui, Telnet, veikti maršrutizatoriuose?
• Ar debesijos saugyklos ištekliai pagal numatytuosius nustatymus yra privatūs?
• Kas gali patvirtinti nuokrypį nuo bazinės konfigūracijos?
• Kaip aptinkate konfigūracijos nuokrypį po pakeitimo?
• Ar galite parodyti neseną konfigūracijos peržiūrą?
• Ar galite parodyti, kad aptiktas nuokrypis buvo ištaisytas?
• Ar tinklo ir debesijos konfigūracijos yra kopijuojamos ir valdomos versijomis?
• Ar grąžinimo į ankstesnę būseną procedūros dokumentuotos ir testuotos?

Stipriausios organizacijos kiekvienai pagrindinei sistemų kategorijai palaiko bazinės konfigūracijos įrodymų rinkinį. Tai sutrumpina auditus, pagerina atsakymus į klientų deramo patikrinimo užklausas ir padeda vadovybei suprasti faktinį kontrolės veiksmingumą.

Paverskite konfigūracijos nuokrypį valdybos lygmens kibernetinės higienos rodikliu

Valdyboms nereikia kiekvienos ugniasienės taisyklės. Joms reikia žinoti, ar kibernetinė higiena gerėja, ar blogėja.

Naudingame saugios konfigūracijos valdymo skyde pateikiama:

• Turto, susieto su patvirtinta bazine konfigūracija, procentinė dalis.
• Turto, sėkmingai pereinančio bazines patikras, procentinė dalis.
• Kritinių bazinės konfigūracijos nuokrypių skaičius.
• Vidutinis atvirų nuokrypių amžius.
• Pasibaigusių išimčių skaičius.
• Aptiktų neautorizuotų konfigūracijos pakeitimų skaičius.
• Privilegijuotų konfigūracijos pakeitimų su patvirtintomis užklausomis procentinė dalis.
• Debesijos viešo pasiekiamumo išimtys.
• Bazinių standartų peržiūros būsena pagal technologijų šeimą.

Šie rodikliai palaiko ISO/IEC 27001:2022 veiklos vertinimą, NIS2 vadovybės priežiūrą ir DORA IRT rizikos ataskaitų teikimą. Jie taip pat natūraliai susiejami su NIST CSF 2.0 valdysenos rezultatais ir COBIT 2019 stebėsenos bei atitikties tikslais.

Padeda paprasta vadovybės taisyklė: jokia kritinė sistema nepaleidžiama į produkcinę aplinką be bazinės konfigūracijos įrodymų. Tai galima taikyti per pakeitimų valdymą, CI/CD vartus, debesijos politikų patikras, infrastruktūros kaip kodo peržiūrą, MDM atitiktį, GPO taikymą arba tinklo konfigūracijos peržiūrą. Brandos lygis gali skirtis, tačiau kontrolės logika neturėtų keistis.

90 dienų saugios konfigūracijos bazinių standartų veiksmų planas

Jei pradedate nuo nulio, nesistenkite iš karto išspręsti kiekvienos konfigūracijos problemos. Naudokite 90 dienų planą.

1–30 dienos: apibrėžkite minimalų bazinį standartą

Identifikuokite kritines turto kategorijas. Kiekvienai priskirkite techninį savininką, rizikos savininką ir tvirtinimo įgaliojimus. Sukurkite pirmą bazinį standartą nustatymams, kurie labiausiai susiję su atsparumu išpirkos reikalaujančiai programinei įrangai, debesijos pasiekiamumu, privilegijuota prieiga, žurnalavimu, šifravimu ir duomenų apsauga.

Sukurkite bazinių standartų registrą ir susiekite jį su ISVS taikymo sritimi, rizikų registru ir taikytinumo pareiškimu. Jei jums taikoma NIS2, nustatykite, ar esate esminis ar svarbus subjektas, arba ar klientai tikisi su NIS2 suderintos kibernetinės higienos. Jei esate finansų subjektas pagal DORA, nustatykite, kuris IRT turtas palaiko kritines arba svarbias funkcijas. Jei tvarkote asmens duomenis, susiekite sistemas su GDPR tvarkymo veiklomis ir duomenų kategorijomis.

31–60 dienos: taikykite ir rinkite įrodymus

Pritaikykite bazinį standartą didelės rizikos sistemų imčiai. Kur įmanoma, naudokite automatizavimą, bet nelaukite idealių priemonių. Eksportuokite konfigūracijas, darykite ekrano kopijas, išsaugokite politikos nustatymus ir registruokite pakeitimų užklausas.

Kiekvienai išimčiai sukurkite rizikos įrašą su galiojimo pabaigos data. Kiekvienam nuokrypiui sukurkite taisomųjų veiksmų užklausą.

61–90 dienos: stebėkite, teikite ataskaitas ir tobulinkite

Atlikite konfigūracijos peržiūrą. Paimkite vieno serverio, vieno galinio įrenginio, vieno tinklo įrenginio ir vienos debesijos aplinkos imtį. Palyginkite faktinius nustatymus su patvirtinta bazine konfigūracija. Dokumentuokite nuokrypius ir korekcinius veiksmus.

Pateikite vadovybei bazinių standartų atitikties ataskaitą. Atnaujinkite taikytinumo pareiškimą ir rizikos tvarkymo planą. Pasikartojančius nuokrypius įtraukite į pagrindinės priežasties analizę. Jei klaidinga konfigūracija sukėlė incidentą arba prie jo prisidėjo, atnaujinkite atitinkamą bazinę konfigūraciją kaip įgytos patirties dalį.

Tai suteikia auditoriams testuotiną objektą, reguliuotojams – suprantamą paaiškinimą, o vadovybei – valdomą kontrolės sritį.

Pabaigai: saugus konfigūravimas yra kibernetinė higiena su įrodymais

NIS2 vartoja kibernetinio saugumo rizikos valdymo priemonių ir bazinės kibernetinės higienos sąvokas. DORA vartoja IRT rizikos, atsparumo, stebėsenos, tęstinumo ir testavimo terminiją. GDPR vartoja tinkamų priemonių ir atskaitomybės terminiją. ISO/IEC 27001:2022 vartoja rizikos tvarkymo, kontrolės priemonių, dokumentuotos informacijos, veiklos vertinimo ir nuolatinio tobulinimo terminiją.

Saugios konfigūracijos baziniai standartai sujungia visa tai.

Jie parodo, kad sistemos nėra diegiamos su nesaugiais numatytaisiais nustatymais. Jie parodo, kad pakeitimai yra kontroliuojami. Jie parodo, kad konfigūracijos nuokrypiai aptinkami. Jie parodo, kad išimčių rizika yra priimta. Jie parodo, kad įrodymai egzistuoja dar prieš auditoriui jų paprašant.

Svarbiausia, jie mažina realią operacinę riziką. Penktadienio popietės ugniasienės taisyklė, viešas debesijos saugyklos segmentas, pamirštas SMBv1 nustatymas, numatytasis IoT slaptažodis ir nežurnalizuojama administravimo konsolė nėra teorinės audito išvados. Tai praktiniai nesėkmės taškai.

Clarysec padeda organizacijoms paversti šiuos nesėkmės taškus kontroliuojamomis, stebimomis ir auditui tinkamomis bazinėmis konfigūracijomis.

Tolesni veiksmai

Jei jūsų organizacijai reikia pagrįsti saugų konfigūravimą ISO/IEC 27001:2022, NIS2 kibernetinės higienos, DORA IRT rizikos valdymo, GDPR atskaitomybės ar klientų patikinimo tikslais, pradėkite nuo Clarysec priemonių rinkinio:

• Naudokite Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planą, kad įgyvendintumėte konfigūracijų valdymą etape „Kontrolės priemonės praktikoje“, 19 žingsnyje, ir patvirtintumėte jį per audito, peržiūros ir tobulinimo etapą, 24 žingsnyje.
• Naudokite Zenith Controls: kelių atitikties sričių vadovą, kad susietumėte konfigūracijų valdymą su palaikančiomis ISO/IEC 27001:2022 kontrolės priemonėmis, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 ir audito metodikomis.
• Naudokite Clarysec politikas, tokias kaip Informacijos saugumo politika, Debesijos paslaugų naudojimo politika, Audito ir atitikties stebėsenos politika, Pažeidžiamumų ir pataisų valdymo politika, Tinklo saugumo politika – MVĮ, Galinių įrenginių apsaugos ir apsaugos nuo kenkėjiškos programinės įrangos politika – MVĮ ir Daiktų interneto (IoT) / operacinių technologijų (OT) saugumo politika – MVĮ, kad apibrėžtumėte, taikytumėte ir įrodymais pagrįstumėte savo bazinius standartus.

Saugi bazinė konfigūracija nėra vien saugumo stiprinimo kontrolinis sąrašas. Tai įrodymas, kad jūsų organizacija žino, kaip atrodo saugi būsena, nuosekliai ją taiko ir gali tai pagrįsti tada, kai svarbiausia.