Turvakonfiguratsiooni baastasemed NIS2 ja DORA jaoks
Reede pärastlõunane väärkonfiguratsioon, millest sai juhatuse probleem
Reedel kell 16.40 kinnitas finantstehnoloogia platvormi arendusjuht näiliselt tavapärase tulemüürimuudatuse. Makseanalüütika teenusepakkujaga seotud integratsiooniprobleemi tõrkeotsinguks avati ajutine reegel. Piletis seisis: „eemaldada pärast testimist“. Test õnnestus. Reegel jäi alles.
Kolm nädalat hiljem tuvastas väline skannimine internetist kättesaadava haldusliidese. Server oli paigatud. Tavakasutajatel oli MFA kasutusel. Haavatavuse skanner ei märkinud ühtegi kriitilist CVE-d. Kuid süsteem ei olnud siiski turvaline, sest selle konfiguratsioon oli triivinud organisatsiooni kinnitatud kõvendatud olekust kõrvale.
Esmaspäeva hommikuks pidas infoturbejuht (CISO) paralleelselt nelja vestlust:
- Regulaator soovis teada, kas talitluspidevus oli mõjutatud.
- Andmekaitseametnik soovis teada, kas isikuandmed olid avalikustunud.
- Juhatus soovis teada, miks „ajutisi“ muudatusi ei tuvastatud.
- ISO/IEC 27001:2022 siseaudiitor soovis tõendusmaterjali selle kohta, et turvakonfiguratsiooni baastasemed olid määratletud, kinnitatud, rakendatud ja seiratud.
Just selles punktis avastavad paljud turbeprogrammid ebamugava tõe. Turvaline seadistamine ei ole pelgalt tehniline kõvendamise kontrollnimekiri. 2026. aastal on turvakonfiguratsiooni baastasemed juhtimise küsimus, küberhügieeni küsimus, IKT-riski küsimus, audititõendite küsimus ja juhatuse vastutuse küsimus.
Sama probleemi teine versioon kordub paljudes reguleeritud organisatsioonides. Maria, kasvava B2B maksetöötleja CISO, juhib tugevaid insenere, paigatud süsteeme ja pilve parimaid tavasid. Kuid NIS2 ja DORA valmisoleku hindamine toob esile ühe punase leiu: formaliseeritud turvakonfiguratsiooni baastasemete puudumise. Tema meeskond teab, kuidas servereid kõvendada, kuid suur osa sellest teadmisest on inseneride peas, mitte kinnitatud standardites, automaatsetes kontrollides ega tõenduspakettides.
See lünk ei ole enam kaitstav. NIS2 nõuab, et juhtorganid kinnitaksid küberriskide juhtimise meetmed ja teeksid nende üle järelevalvet. DORA nõuab dokumenteeritud IKT-riski juhtimise raamistikku ja vastupidavaid IKT-toiminguid. GDPR nõuab asjakohaseid tehnilisi ja korralduslikke meetmeid. ISO/IEC 27001:2022 nõuab riskipõhist kontrollide valikut, rakendamist, seiret, auditit ja pidevat täiustamist.
Turvakonfiguratsiooni baastasemed seovad need kohustused üheks praktiliseks kontrollisüsteemiks: määratle baastase, määra vastutus, rakenda see provisioneerimisel, halda erandeid, tuvasta triiv, esita tõendusmaterjal ning paranda pärast auditeid või intsidente.
Nagu Clarysec’i Zenith Blueprint: audiitori 30-sammuline teekaart ütleb etapis Controls in Action, Step 19, Technological Controls I:
„Paljud rikkumised ei tulene tarkvara puudustest, vaid halbadest konfiguratsioonivalikutest. Vaikeparoolid jäetakse muutmata, ebaturvalised teenused lubatakse, tarbetud pordid jäetakse avatuks või süsteemid avaldatakse internetti ilma põhjenduseta.“
See lause võtab kokku, miks turvakonfiguratsiooni baastasemed on nüüd keskne vastupidavuse kontrollimeede. Need määratlevad, mida turvalisus tähendab, enne kui seda küsib audiitor, regulaator, klient või ründaja.
Mis turvakonfiguratsiooni baastase tegelikult on
Turvakonfiguratsiooni baastase on kinnitatud, dokumenteeritud ja korratav turvaseadistuste kogum konkreetse süsteemitüübi jaoks. Seda saab rakendada Windowsi serveritele, Linuxi hostidele, võrguseadmetele, SaaS-i rentnikele, pilvesalvestusele, Kubernetes’e klastritele, andmebaasidele, tulemüüridele, lõppseadmetele, identiteediplatvormidele, asjade interneti seadmetele ja operatsioonitehnoloogiale.
Tugev baastase vastab praktilistele küsimustele:
- Millised teenused on vaikimisi keelatud?
- Milliseid porte võib väliselt avada?
- Millised autentimise ja MFA seadistused on kohustuslikud?
- Millised logimise seadistused tuleb lubada?
- Millised krüptimise seadistused on nõutavad?
- Millised haldusliidesed on piiratud?
- Millised pilveressursid võivad olla avalikud ja kelle kinnitusega?
- Millised kõrvalekalded nõuavad riski aktsepteerimist?
- Kui sageli kontrollime konfiguratsioonitriivi?
- Milline tõendusmaterjal tõendab, et baastase toimib?
Kõige levinum viga on käsitleda baastasemeid inseneritehniliste eelistustena, mitte juhitud kontrollimeetmetena. Linuxi administraatori kontrollnimekiri, pilvearhitekti wiki-leht ja võrguinseneri tulemüürireeglite tava võivad kõik olla kasulikud, kuid need ei muutu auditikõlblikuks enne, kui need on kinnitatud, riskidega seotud, järjepidevalt rakendatud ja seiratud.
Seetõttu on ISO/IEC 27001:2022 nii kasulik lähtekoht. Punktid 4.1 kuni 4.3 nõuavad, et organisatsioon mõistaks sisemisi ja väliseid küsimusi, huvitatud osapooli ning ISMS-i kohaldamisala, sealhulgas õiguslikke, regulatiivseid, lepingulisi ja kolmandate osapoolte nõudeid. Punktid 6.1.2 ja 6.1.3 nõuavad infoturbe riskihindamist, riskikäsitlust, kontrollimeetmete valikut, kohaldatavuse deklaratsiooni ja riskiomaniku heakskiitu. Punktid 8.2 ja 8.3 nõuavad riskihindamiste ja riskikäsitluse kordamist kavandatud ajavahemike järel või oluliste muudatuste korral.
Lisa A muudab tehnilise ootuse konkreetseks kontrolli A.8.9 konfiguratsioonihaldus kaudu, mida toetavad varade register, haavatavuste haldus, muudatuste juhtimine, logimine, seire, juurdepääsukontroll, krüptograafia, pilveteenuste kasutamine ja dokumenteeritud tööprotseduurid.
Tulemuseks on lihtne, kuid tugev juhtimispõhimõte: kui organisatsioon ei suuda näidata, mida turvalisus iga olulisema süsteemitüübi puhul tähendab, ei suuda ta veenvalt tõendada küberhügieeni NIS2 alusel, IKT-riski kontrolli DORA alusel, vastutust GDPR alusel ega kontrollimeetmete tõhusust ISO/IEC 27001:2022 alusel.
Miks NIS2, DORA ja GDPR muudavad baastasemed vältimatuks
NIS2, DORA ja GDPR kasutavad erinevat sõnastust, kuid koonduvad sama operatiivse nõude ümber: süsteemid peavad olema turvaliselt seadistatud, pidevalt seiratud ja vastutuspõhise riskijuhtimise kaudu juhitud.
NIS2 Article 20 nõuab, et oluliste ja tähtsate üksuste juhtorganid kinnitaksid küberriskide juhtimise meetmed, teeksid järelevalvet nende rakendamise üle ja läbiksid küberturbe koolituse. Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja korralduslikke meetmeid. Turvakonfiguratsiooni baastasemed toetavad Article 21(2)(a) riskianalüüsi ja infosüsteemide turbe poliitikaid, Article 21(2)(e) võrgu- ja infosüsteemide hankimise, arendamise ja hoolduse turvet, sealhulgas haavatavuste käsitlemist, Article 21(2)(f) tõhususe hindamise poliitikaid ja protseduure, Article 21(2)(g) põhilist küberhügieeni ja küberturbe koolitust, Article 21(2)(h) krüptograafiat, Article 21(2)(i) juurdepääsukontrolli ja varahaldust ning Article 21(2)(j) mitmefaktorilist autentimist ja turvalist sidet.
DORA kohaldub alates 17. jaanuarist 2025 ning toimib hõlmatud finantsüksuste sektoripõhise operatsioonilise toimepidevuse reeglistikuna. Articles 5 ja 6 nõuavad juhtimist ja dokumenteeritud IKT-riski juhtimise raamistikku. Article 8 nõuab IKT-varade, teabevarade, IKT-toega ärifunktsioonide ja sõltuvuste tuvastamist. Article 9 nõuab kaitse- ja ennetusmeetmeid, sealhulgas turbepoliitikaid, protseduure, protokolle ja tööriistu IKT-süsteemide jaoks, turvalist andmeedastust, juurdepääsukontrolli, tugevat autentimist, krüptograafiliste võtmete kaitset, muudatuste juhtimist, paikamist ja uuendusi. Articles 10 kuni 14 laiendavad mudelit tuvastamisele, reageerimisele, taastamisele, varundamisele, taastamise kontrollile, õppimisele ja kommunikatsioonile.
GDPR lisab andmekaitse vaate. Articles 5 ja 32 nõuavad terviklust, konfidentsiaalsust, töötlemise turvalisust ja vastutust asjakohaste tehniliste ja korralduslike meetmete kaudu. Avalikud pilvesalvestusmahutid, liigselt avatud andmebaasid, ebaturvalised vaikeseadistused ja ülemäärane haldusjuurdepääs ei ole üksnes taristu nõrkused. Need võivad muutuda isikuandmete kaitse rikkumisteks.
Üks turvakonfiguratsiooni baastasemete programm võib toetada kõiki kolme režiimi ilma dubleerivaid tõendusvooge loomata.
| Nõudevaldkond | Turvakonfiguratsiooni panus | Tüüpiline tõendusmaterjal |
|---|---|---|
| ISO/IEC 27001:2022 riskikäsitlus | Tõendab valitud ja rakendatud kontrollimeetmeid turvaliste süsteemiolekute jaoks | Riskikäsitluskava, kohaldatavuse deklaratsioon, kinnitatud baastase |
| NIS2 küberhügieen | Näitab turvalisi vaikeseadistusi, kontrollitud avatust ja tõhususe hindamist | Baastasemete register, triiviaruanded, juhtkonna aruandlus |
| DORA IKT-riski juhtimine | Seob IKT-varade kaitse, muudatuste kontrolli, paikamise ja seire | IKT-varade vastendus, muudatuste piletid, konfiguratsiooni vastavuse aruanded |
| GDPR vastutus | Tõendab asjakohaseid meetmeid isikuandmeid töötlevate süsteemide jaoks | Andmesüsteemide vastendus, krüptimise seadistused, juurdepääsuõiguste ülevaatused |
| Kliendikindlus | Annab korratava tõendusmaterjali hoolsuskontrolli küsimustike jaoks | Tõenduspakett, ekraanitõmmised, eksportandmed, erandiregister |
Clarysec’i baastaseme mudel: poliitika, protseduur ja platvormi tõendusmaterjal
Clarysec käsitleb turvalist seadistamist korratava kontrollisüsteemina, mitte ühekordse kõvendamisprojektina. Baastase peab olema poliitikaga volitatud, protseduurideks tõlgitud, tehniliste kontrollimeetmetega rakendatud ja tõendusmaterjaliga kinnitatud.
Infoturbepoliitika seab selle ootuse ettevõtte tasandil:
„Organisatsioon peab säilitama minimaalse kontrollibaasi, mis tuleneb ISO/IEC 27001 lisa A nõuetest ja mida vajaduse korral täiendatakse ISO/IEC 27002, NIST SP 800-53 ja COBIT 2019 kontrollimeetmetega.“
Jaotisest „Riskikäsitlus ja erandid“, poliitika punkt 7.2.1.
See punkt takistab konfiguratsiooni kõvendamisel muutumast isiklike eelistuste kogumiks. See seob minimaalse kontrollibaasi tunnustatud raamistikega.
Pilvekeskkondade puhul täpsustab nõuet Pilveteenuste kasutamise poliitika:
„Kõik pilvekeskkonnad peavad vastama dokumenteeritud lähteseadistusele, mille on kinnitanud pilveturbe arhitekt.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.3.1.
Auditi ja vastavusseire poliitika muudab seejärel baastaseme seiratavaks kontrollimeetmeks:
„Konfiguratsiooni vastavuse, haavatavuste halduse, paikade staatuse ja privilegeeritud juurdepääsu seireks tuleb kasutusele võtta automatiseeritud tööriistad.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.4.1.
Konfiguratsioon on lahutamatult seotud ka haavatavuste ja paikade haldusega. Haavatavuste ja paikade halduse poliitika sätestab:
„Haavatavuste kõrvaldamine peab olema kooskõlas lähteseadistuse ja süsteemi kõvendamise standarditega.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.4.1.
See on oluline. Süsteem võib olla paigatud, kuid jääda siiski ebaturvaliseks, kui SMBv1 on lubatud, haldusliidesed on avatud, logimine on keelatud või nõrgad autentimisseadistused on endiselt kasutusel. Zenith Controls: ristvastavuse juhend käsitleb konfiguratsioonihaldust ennetava kontrollimeetmena, mis kaitseb konfidentsiaalsust, terviklust ja käideldavust ning mille operatiivne võimekus seisneb turvalises seadistamises. Zenith Controls selgitab ka konfiguratsioonihalduse ja haavatavuste halduse sõltuvust:
„Haavatavuste haldus sõltub teadaolevatest konfiguratsioonidest. Ilma määratletud baastasemeta ei ole võimalik tagada, et paigad rakendatakse järjepidevalt.“
See on tõendusloogika, mida audiitorid ja regulaatorid üha enam ootavad: kontrollisüsteem, mitte eraldiseisvad tehnilised ülesanded.
ISO/IEC 27001:2022 A.8.9 vastendamine toetavate kontrollidega
ISO/IEC 27001:2022 lisa A kontroll A.8.9 konfiguratsioonihaldus on lähtekoht, kuid seda ei tohiks käsitleda väikese eraldiseisva dokumendina. See sõltub laiemast kontrolliperekonnast.
| ISO/IEC 27001:2022 lisa A kontroll | Miks see on turvakonfiguratsiooni baastasemete jaoks oluline |
|---|---|
| A.5.9 teabe ja muude seotud varade register | Iga teadaolev vara vajab määratud baastaset. Tundmatud varad loovad tundmatu konfiguratsiooniriski. |
| A.8.8 tehniliste haavatavuste haldus | Skannimine ja paikamine sõltuvad teadaolevatest konfiguratsioonidest ja eeldatavatest süsteemiolekutest. |
| A.8.32 muudatuste juhtimine | Baastasemed määratlevad kinnitatud olekud, muudatuste juhtimine kontrollib kinnitatud liikumist olekute vahel. |
| A.8.1 kasutajate lõppseadmed | Lõppseadmete paigaldused vajavad kõvendatud seadistusi, krüptimist, turbeagente ja piiratud teenuseid. |
| A.8.2 privilegeeritud juurdepääsu õigused | Konfiguratsioone tohivad muuta üksnes volitatud administraatorid ning vaikekontod tuleb eemaldada või turvata. |
| A.8.5 turvaline autentimine | Parooli-, lukustus-, MFA- ja seansireeglid on sageli baastaseme seadistused. |
| A.8.15 logimine | Turbe-, haldus- ja konfiguratsioonimuudatuste sündmused tuleb tõendusmaterjali ja uurimise jaoks talletada. |
| A.8.16 seiretegevused | Triivi tuvastamine ja kahtlased konfiguratsioonimuudatused nõuavad aktiivset seiret. |
| A.5.37 dokumenteeritud tööprotseduurid | Paigaldusprotseduurid, konfiguratsiooni kontrollnimekirjad ja läbivaatamise sammud muudavad baastaseme rakendamise korratavaks. |
| A.5.36 infoturbe poliitikate, reeglite ja standardite järgimine | Vastavuskontrollid tõendavad, et süsteemid vastavad jätkuvalt kinnitatud baastasemetele. |
See kontrollidevaheline seos on põhjus, miks Clarysec soovitab hallata turvalist seadistamist ISMS-i võimekusena, millel on omanikud, tõendusmaterjal, mõõdikud ja juhtkonna aruandlus.
Laiem vastendustabel aitab sama baastasemete programmi teistesse raamistikesse tõlkida.
| Raamistik | Asjakohane nõue või kontroll | Turvakonfiguratsiooni tõendusmaterjal |
|---|---|---|
| NIS2 | Article 21 küberriskide juhtimise meetmed, sealhulgas küberhügieen, turvaline hooldus, haavatavuste käsitlemine, tõhususe hindamine, juurdepääsukontroll ja varahaldus | Baastaseme standardid, triiviaruanded, erandikirjed, juhtkonna järelevalve |
| DORA | Articles 6, 8 ja 9 IKT-riski juhtimise, IKT-varade tuvastamise, kaitse ja ennetuse kohta | IKT baastasemete register, varade ja baastasemete vastendus, muudatuste ja paikade tõendusmaterjal |
| GDPR | Articles 5 ja 32 tervikluse, konfidentsiaalsuse, töötlemise turvalisuse ja vastutuse kohta | Krüptimise seadistused, juurdepääsuseadistused, turvaline pilvekonfiguratsioon, läbivaatamise kirjed |
| NIST SP 800-53 Rev. 5 | CM-2 Baseline Configuration, CM-3 Configuration Change Control, CM-6 Configuration Settings, CM-7 Least Functionality, RA-5 Vulnerability Monitoring and Scanning, SI-4 System Monitoring | Konfiguratsiooni baastasemed, muudatuste kirjed, haavatavuse skannimise tulemused, seire väljundid |
| COBIT 2019 | APO13 Managed Security, BAI06 Managed IT Changes, BAI10 Managed Configuration, DSS05 Managed Security Services, MEA03 Managed Compliance With External Requirements | Juhtimismõõdikud, kinnitatud muudatused, konfiguratsioonikirjed, vastavuse aruandlus |
Praktiline baastaseme struktuur, mida saab sel kuul rakendada
Kõige levinum viga on püüda kirjutada täiuslik 80-leheküljeline kõvendamise standard enne, kui midagi rakendatakse. Alusta iga olulisema tehnoloogiapere jaoks minimaalsest, kuid auditikõlblikust baastasemest ning täiusta seda seejärel automatiseerimise ja läbivaatamise kaudu.
| Baastaseme komponent | Näidisnõue | Säilitatav tõendusmaterjal |
|---|---|---|
| Kohaldamisala | Windowsi serverid, Linuxi serverid, lõppseadmed, tulemüürid, pilvesalvestus, identiteedirentnik ja andmebaasid | Baastasemete register varakategooriatega |
| Omandivastutus | Igal baastasemel on tehniline omanik, riskiomanik ja kinnitaja | RACI või kontrollivastutuse maatriks |
| Kinnitatud paigaldus | Kõvendatud kujutis, taristu koodina mall, GPO, MDM-profiil või käsitsi paigalduse kontrollnimekiri | Malli eksport, ekraanitõmmis, repositooriumi sissekanne või kontrollnimekiri |
| Võrgu kokkupuude | Väliselt on avatud ainult kinnitatud pordid ja teenused | Tulemüürireeglite eksport, pilve turbegrupi aruanne |
| Autentimine | MFA haldusjuurdepääsuks, vaikekontode puudumine, turvalised parooli- ja lukustusseadistused | Identiteedipoliitika ekraanitõmmis, administraatorijuurdepääsu läbivaatamine |
| Logimine | Turbe-, haldus-, autentimis- ja konfiguratsioonimuudatuste logid on lubatud | SIEM-i juhtpaneel, logiallikate register |
| Krüptimine | Nõutud juhtudel on lubatud krüptimine puhkeolekus ja ülekandel | Konfiguratsiooni ekraanitõmmis, võtmehalduse kirje |
| Muudatuste kontroll | Baastaseme muudatused ja erandid nõuavad piletit, heakskiitu, testimist ja tagasipööramiskava | Muudatuse pilet ja kinnituste ajalugu |
| Triivi seire | Automatiseeritud või ajastatud kontrollid võrdlevad tegelikke seadistusi kinnitatud baastasemega | Konfiguratsiooni vastavuse aruanne |
| Läbivaatamise sagedus | Baastasemed vaadatakse üle vähemalt kord aastas ning pärast olulisi intsidente, arhitektuurimuudatusi või regulatiivseid muudatusi | Läbivaatamise protokollid, ajakohastatud versiooniajalugu |
Pilvesalvestuse baastaseme esimene versioon võib sisaldada nõudeid, et avalik juurdepääs on vaikimisi keelatud, krüptimine puhkeolekus on lubatud, juurdepääsulogid on lubatud, haldusjuurdepääs on piiratud kinnitatud rühmadega, MFA on privilegeeritud konsoolijuurdepääsuks nõutav, versioonimine on lubatud seal, kus taastamisnõuded seda eeldavad, replikatsioon on piiratud kinnitatud piirkondadega ning muudatusi tehakse ainult kinnitatud taristu koodina torustike kaudu.
Makse töötlemist toetava Windows Server 2022 baastaseme esimene versioon võib sisaldada nõudeid, et SMBv1 on keelatud, mittevajalikud teenused on keelatud, RDP on piiratud kõvendatud hüppeserveriga, Windows Defender Firewall on lubatud vaikimisi keela-põhimõttega, kohalikud administraatorikontod on kontrolli all, sündmuslogid edastatakse SIEM-i, lõppseadmete kaitse on lubatud ning haldusmuudatused on seotud kinnitatud piletitega.
Iga baastaseme jaoks loo väike tõenduspakett:
- Kinnitatud baastaseme dokument.
- Ekraanitõmmis või eksporditud poliitika, mis näitab rakendatud konfiguratsiooni.
- Baastasemega hõlmatud varade loend.
- Muudatuse pilet, mis näitab, kuidas uuendusi kinnitatakse.
- Konfiguratsiooni vastavuse aruanne või käsitsi läbivaatamise kirje.
See on otseselt kooskõlas Zenith Blueprintiga, etapis Controls in Action, Step 19, kus Clarysec soovitab organisatsioonidel koostada konfiguratsiooni kontrollnimekirjad peamiste süsteemitüüpide jaoks, rakendada seadistusi järjepidevalt provisioneerimisel võimaluse korral automatiseerimise kaudu ning seejärel regulaarselt auditeerida juurutatud süsteeme. Blueprint annab ka praktilise auditimeetodi:
„Vali mõned esinduslikud süsteemid (nt üks server, üks kommutaator, üks lõppkasutaja arvuti) ja valideeri, et nende konfiguratsioon vastab sinu turvalisele baastasemele. Dokumenteeri kõrvalekalded ja parandusmeetmed.“
VKE-de jaoks on selline esinduslik valim sageli kiireim tee mitteametlikust kõvendamisest auditivalmis tõendusmaterjalini.
VKE kõvendamise näited, mis vähendavad riski kiiresti
Turvaline seadistamine ei ole ainult suurte ettevõtete pilveprobleem. VKE-d saavad sageli suurima riskivähenduse mõnest selgest baastaseme reeglist.
Võrguturbe poliitika – VKE sätestab:
„Avalikku internetti võib avada ainult hädavajalikud pordid (nt HTTPS, VPN); kõik ülejäänud tuleb sulgeda või filtreerida.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.1.3.
See nõuab ka muudatuste distsipliini:
„Kõik võrgukonfiguratsiooni muudatused (tulemüüri reeglid, kommutaatori ACL-id, marsruutimistabelid) peavad järgima dokumenteeritud muudatuste juhtimise protsessi.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.9.1.
Samuti loob see läbivaatamise sageduse:
„IT-tugiteenuse osutaja peab igal aastal läbi vaatama tulemüüri reeglid, võrguarhitektuuri ja traadita võrgu konfiguratsioonid.“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.6.1.
Lõppseadmete baastasemed vajavad samaväärset tähelepanu. Clarysec’i Lõppseadmete kaitse ja pahavaratõrje poliitika – VKE sätestab:
„Seadmed peavad keelama aegunud protokollid (nt SMBv1), mida pahavara võib ära kasutada.“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.2.1.3.
IoT- ja OT-keskkondades on ebaturvalised vaikeseadistused jätkuvalt korduv kokkupuude. Asjade interneti (IoT) / operatsioonitehnoloogia (OT) turbepoliitika – VKE sätestab:
„Vaike- või kõvakodeeritud paroolid tuleb enne seadmete aktiveerimist muuta.“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.3.2.
Need poliitikapunktid ei ole abstraktsed avaldused. Need on baastaseme nõuded, mida saab testida, tõendada ja jälgida. VKE jaoks, kes valmistub kliendi hoolsuskontrolliks, NIS2 tarnijaülevaatuseks, küberkindlustuseks või ISO/IEC 27001:2022 sertifitseerimiseks, loovad need kohese väärtuse.
Erandite käsitlemine: kontroll, mis eristab küpsust paberitööst
Igal baastasemel esineb erandeid. Pärandrakendus võib vajada vana protokolli. Tarnija seade ei pruugi toetada eelistatud krüptimisseadistust. Migreerimise jaoks võib olla vaja ajutist tulemüüri avamist. Küsimus ei ole selles, kas erandeid esineb. Küsimus on selles, kas neid juhitakse.
Küps erandikirje sisaldab järgmist:
- Baastaseme nõue, mida rikutakse.
- Äripõhjendus.
- Mõjutatud vara ja omanik.
- Riskihindamine.
- Kompenseerivad kontrollimeetmed.
- Kinnitaja.
- Aegumiskuupäev.
- Seirenõue.
- Parandusmeetmete plaan.
Siin töötavad ISO/IEC 27001:2022 riskikäsitlus ja DORA proportsionaalsus koos. ISO/IEC 27001:2022 nõuab, et kontrolliotsused oleksid põhjendatud riskihindamise, riskikäsitluse, kohaldatavuse deklaratsiooni ja riskiomaniku heakskiidu kaudu. DORA lubab proportsionaalset rakendamist suuruse, riskiprofiili ning teenuste olemuse, ulatuse ja keerukuse alusel, kuid eeldab siiski dokumenteeritud IKT-riski juhtimist, seiret, talitluspidevust, testimist ja teadlikkust.
Proportsionaalsus ei anna luba baastasemeid vahele jätta. See on nõue neid arukalt skaleerida.
Mikro- või väiksema finantsüksuse puhul, millele kohaldub lihtsustatud IKT-riski raamistik, võib baastase olla lühike ja toetuda käsitsi valimile. Suurema finantsüksuse puhul vajab sama valdkond tõenäoliselt automatiseeritud konfiguratsioonikontrolle, siseauditi kaasamist, iga-aastast testimist ja aruandlust juhtorganile.
Muudatuste haldamise poliitika tuletab organisatsioonidele samuti meelde, et tähelepanu tuleb pöörata järgmisele:
„Konfiguratsioonitriiv või rikkumine pärast kinnitatud muudatusi.“
Jaotisest „Rakendamine ja vastavus“, poliitika punkt 8.1.2.3.
See fraas seob muudatuste kontrolli triivi tuvastamisega. Muudatus võib olla kinnitatud, kuid tekitada siiski riski, kui rakendatud olek erineb kinnitatud olekust või kui ajutine seadistus jääb pärast muudatusakna sulgemist alles.
Ühe tõendusahela loomine paljude vastavuskohustuste jaoks
Turvakonfiguratsiooni baastase ei tohiks luua viit eraldi vastavuse töövoogu. Clarysec’i mudel kasutab ühte tõendusahelat, mis on vastendatud mitmele kohustusele.
| Tõendusartefakt | Kasutus ISO/IEC 27001:2022 raames | Kasutus NIS2 raames | Kasutus DORA raames | Kasutus GDPR raames | Kasutus NIST ja COBIT 2019 raames |
|---|---|---|---|---|---|
| Baastaseme standard | Toetab lisa A kontrollide valikut ja riskikäsitlust | Tõendab küberhügieeni ja turvalist hooldust | Toetab IKT-riski raamistikku ja turvalisi IKT-toiminguid | Näitab asjakohaseid tehnilisi meetmeid | Toetab konfiguratsiooniseadeid ja juhtimiseesmärke |
| Vara ja baastaseme vastendus | Toetab varade registrit ja kohaldamisala | Näitab, et teenuse osutamiseks kasutatavad süsteemid on kontrolli all | Toetab IKT-varade ja sõltuvuste tuvastamist | Tuvastab isikuandmeid töötlevad süsteemid | Toetab registreid ja komponentide haldust |
| Muudatuste piletid | Näitab kontrollitud rakendamist ja kõrvalekaldeid | Näitab riskipõhist operatiivset kontrolli | Toetab muudatuste juhtimist, paikamist ja uuendusi | Näitab vastutust isikuandmeid mõjutavate muudatuste eest | Toetab muudatuste kontrolli ja auditijälgi |
| Triiviaruanded | Näitab seiret ja tõhususe hindamist | Näitab tehniliste meetmete hindamist | Näitab pidevat seiret ja kontrolli | Näitab andmete jätkuvat kaitset | Toetab pidevat seiret ja vastavust |
| Erandiregister | Näitab riskiomaniku heakskiitu jääkriskile | Näitab proportsionaalset riskijuhtimist | Näitab IKT-riski aktsepteerimist ja parandusmeetmete jälgimist | Näitab vastutust ja kaitsemeetmeid | Toetab riskile reageerimist ja juhtkonna järelevalvet |
| Läbivaatamise protokollid | Toetab juhtkonna läbivaatamist ja pidevat täiustamist | Toetab juhtkonna järelevalvet Article 20 alusel | Toetab juhtorgani vastutust | Toetab meetmete läbivaatamist ja ajakohastamist | Toetab juhtimisaruandlust ja mõõdikuid |
Võti on jälgitavus. Zenith Blueprint, etapp Audit, Review and Improvement, Step 24, juhendab organisatsioone ajakohastama kohaldatavuse deklaratsiooni ja ristkontrollima seda riskikäsitluskavaga. Kui kontroll on kohaldatav, on vaja põhjendust. See põhjendus peab olema seotud riski, õigusliku kohustuse, lepingulise nõude või ärivajadusega.
Turvakonfiguratsiooni puhul peaks SoA kirje A.8.9 kohta viitama turvakonfiguratsiooni baastaseme standardile, hõlmatud varakategooriatele, baastaseme omanikele, muudatuste juhtimise protseduurile, seiremeetodile, erandiprotsessile, läbivaatamise sagedusele ja ristvastavuse kohustustele, nagu NIS2 Article 21, DORA Articles 6, 8 ja 9, GDPR Article 32 ning kliendikohustused.
Kuidas audiitorid testivad turvakonfiguratsiooni baastasemeid
Turvaline seadistamine on audiitoritele atraktiivne, sest see on tõendusmaterjali poolest rikas. Seda saab testida dokumentide, intervjuude, valimite ja tehnilise kontrolli kaudu.
| Auditi vaatenurk | Mida audiitor küsib | Toimiv tõendusmaterjal |
|---|---|---|
| ISO/IEC 27001:2022 ISMS-i audiitor | Kas konfiguratsioonihaldus on kohaldamisalas, riskihinnatud, SoA-s valitud, rakendatud ja seiratud? | SoA kirje, riskikäsitluskava, baastaseme standard, näidissüsteemi tõendusmaterjal, siseauditi tulemused |
| Tehniline audiitor | Kas tegelikud süsteemid vastavad kinnitatud baastasemetele ja kõrvalekalded kõrvaldatakse? | Konfiguratsiooni eksportandmed, ekraanitõmmised, GPO eksportandmed, triiviaruanded, parandusmeetmete kirjed |
| NIST hindaja | Kas baaskonfiguratsioonid on dokumenteeritud, turvalised seadistused rakendatud, registrid ajakohased ja kõrvalekalded seiratud? | Kõvendamise kontrollnimekirjad, CMDB, automatiseeritud vastavusaruanded, võrdlusbaasi skannimise väljundid |
| COBIT 2019 audiitor | Kas konfiguratsiooni baastasemed on juhitud, kinnitatud, seiratud ja juhtkonnale raporteeritud? | Juhtimismõõdikud, juhtkonna aruanded, muudatuste piletid, erandiregister |
| ISACA ITAF-iga kooskõlas audiitor | Kas on piisav ja asjakohane tõendusmaterjal, et kontroll on kavandatud ja toimib tõhusalt? | Intervjuud, läbikäigud, konfiguratsiooniauditi kirjed, väärkonfiguratsiooniga seotud intsidendikirjed |
Praktilised küsimused on etteaimatavad:
- Kas kasutate uute serverite paigaldamisel kõvendamise kontrollnimekirja?
- Kuidas takistate ebaturvaliste teenuste, näiteks Telneti, töötamist ruuterites?
- Kas pilvesalvestuse ressursid on vaikimisi privaatsed?
- Kes võib kinnitada kõrvalekalde baastasemest?
- Kuidas tuvastate triivi pärast muudatust?
- Kas saate näidata hiljutist konfiguratsiooni läbivaatamist?
- Kas saate näidata, et tuvastatud kõrvalekalle kõrvaldati?
- Kas võrgu- ja pilvekonfiguratsioonid on varundatud ja versioonitud?
- Kas tagasipööramise protseduurid on dokumenteeritud ja testitud?
Tugevaimad organisatsioonid säilitavad iga olulisema süsteemikategooria kohta baastaseme tõenduspaketi. See lühendab auditeid, parandab klientide hoolsuskontrolli vastuseid ja aitab juhtkonnal mõista kontrollimeetmete tegelikku toimivust.
Muuda konfiguratsioonitriiv juhatuse tasandi küberhügieeni mõõdikuks
Juhatus ei vaja iga tulemüürireeglit. Küll aga peab juhatus teadma, kas küberhügieen paraneb või halveneb.
Kasulik turvakonfiguratsiooni juhtpaneel sisaldab järgmist:
- Kinnitatud baastasemega vastendatud varade osakaal.
- Baastaseme kontrollid läbinud varade osakaal.
- Kriitiliste baastaseme kõrvalekallete arv.
- Avatud kõrvalekallete keskmine vanus.
- Aegunud erandite arv.
- Tuvastatud autoriseerimata konfiguratsioonimuudatuste arv.
- Kinnitatud piletitega privilegeeritud konfiguratsioonimuudatuste osakaal.
- Pilve avaliku kokkupuute erandid.
- Baastaseme läbivaatamise staatus tehnoloogiapere kaupa.
Need mõõdikud toetavad ISO/IEC 27001:2022 toimivuse hindamist, NIS2 juhtkonna järelevalvet ja DORA IKT-riski aruandlust. Need vastenduvad loomulikult ka NIST CSF 2.0 juhtimistulemustele ning COBIT 2019 seire- ja vastavuseesmärkidele.
Lihtne juhtkonna reegel aitab: ükski kriitiline süsteem ei lähe tootmiskeskkonda ilma baastaseme tõendusmaterjalita. Seda saab rakendada muudatuste juhtimise, CI/CD väravate, pilvepoliitika kontrollide, taristu koodina läbivaatamise, MDM-i vastavuse, GPO rakendamise või võrgukonfiguratsiooni läbivaatamise kaudu. Küpsustase võib erineda, kuid kontrolliloogika ei tohiks muutuda.
90-päevane turvakonfiguratsiooni baastasemete tegevuskava
Kui alustad nullist, ära püüa lahendada kõiki konfiguratsiooniprobleeme korraga. Kasuta 90-päevast plaani.
Päevad 1–30: määratle minimaalne baastase
Tuvasta kriitilised varakategooriad. Määra igaühele tehniline omanik, riskiomanik ja kinnitaja. Loo esimene baastase seadistustele, mis on kõige olulisemad lunavarakindluse, pilve kokkupuute, privilegeeritud juurdepääsu, logimise, krüptimise ja andmekaitse jaoks.
Loo baastasemete register ja seo see ISMS-i kohaldamisala, riskiregistri ja kohaldatavuse deklaratsiooniga. Kui sulle kohaldub NIS2, tuvasta, kas oled oluline või tähtis üksus või kas kliendid ootavad NIS2-ga kooskõlas küberhügieeni. Kui oled DORA alusel finantsüksus, tuvasta, millised IKT-varad toetavad kriitilisi või olulisi funktsioone. Kui töötled isikuandmeid, vasta süsteemid GDPR töötlemistoimingutele ja andmekategooriatele.
Päevad 31–60: rakenda ja kogu tõendusmaterjal
Rakenda baastase kõrge riskiga süsteemide valimile. Kasuta automatiseerimist, kus võimalik, kuid ära oota täiuslikke tööriistu. Ekspordi konfiguratsioonid, tee ekraanitõmmised, salvesta poliitikaseadistused ja registreeri muudatuste piletid.
Loo iga erandi kohta riskikirje koos aegumiskuupäevaga. Loo iga kõrvalekalde kohta parandusmeetme pilet.
Päevad 61–90: seira, raporteeri ja täiusta
Tee konfiguratsiooni läbivaatamine. Vali valimisse üks server, üks lõppseade, üks võrguseade ja üks pilvekeskkond. Võrdle tegelikke seadistusi kinnitatud baastasemega. Dokumenteeri kõrvalekalded ja parandusmeetmed.
Raporteeri baastaseme vastavus juhtkonnale. Ajakohasta kohaldatavuse deklaratsioon ja riskikäsitluskava. Suuna korduvad kõrvalekalded algpõhjuse analüüsi. Kui väärkonfiguratsioon põhjustas intsidendi või aitas sellele kaasa, ajakohasta õppetundide osana asjakohast baastaset.
See annab audiitoritele midagi testitavat, regulaatoritele midagi arusaadavat ja juhtkonnale midagi juhitavat.
Lõppmõte: turvaline seadistamine on tõendatav küberhügieen
NIS2 kasutab küberriskide juhtimise meetmete ja põhilise küberhügieeni keelt. DORA kasutab IKT-riski, vastupidavuse, seire, talitluspidevuse ja testimise keelt. GDPR kasutab asjakohaste meetmete ja vastutuse keelt. ISO/IEC 27001:2022 kasutab riskikäsitluse, kontrollimeetmete, dokumenteeritud teabe, toimivuse hindamise ja pideva täiustamise keelt.
Turvakonfiguratsiooni baastasemed seovad need kõik kokku.
Need näitavad, et süsteeme ei juurutata ebaturvaliste vaikeseadistustega. Need näitavad, et muudatused on kontrolli all. Need näitavad, et triiv tuvastatakse. Need näitavad, et erandid aktsepteeritakse riskipõhiselt. Need näitavad, et tõendusmaterjal on olemas enne, kui audiitor seda küsib.
Kõige olulisem on, et need vähendavad tegelikku operatiivset riski. Reede pärastlõunane tulemüürireegel, avalik pilvesalvestusmahuti, unustatud SMBv1 seadistus, vaikimisi IoT parool ja logimata halduskonsool ei ole teoreetilised auditileiud. Need on praktilised rikkepunktid.
Clarysec aitab organisatsioonidel muuta need rikkepunktid kontrollitud, seiratud ja auditikõlblikeks baastasemeteks.
Järgmised sammud
Kui sinu organisatsioon peab tõendama turvalist seadistamist ISO/IEC 27001:2022, NIS2 küberhügieeni, DORA IKT-riski juhtimise, GDPR vastutuse või kliendikindluse jaoks, alusta Clarysec’i tööriistakomplektist:
- Kasuta Zenith Blueprint: audiitori 30-sammuline teekaart, et rakendada konfiguratsioonihaldust etapis Controls in Action, Step 19, ning valideerida seda etapis Audit, Review and Improvement, Step 24.
- Kasuta Zenith Controls: ristvastavuse juhend, et vastendada konfiguratsioonihaldus toetavate ISO/IEC 27001:2022 kontrollide, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 ja auditimetoodikatega.
- Kasuta Clarysec poliitikaid, nagu Infoturbepoliitika, Pilveteenuste kasutamise poliitika, Auditi ja vastavusseire poliitika, Haavatavuste ja paikade halduse poliitika, Võrguturbe poliitika – VKE, Lõppseadmete kaitse ja pahavaratõrje poliitika – VKE ja Asjade interneti (IoT) / operatsioonitehnoloogia (OT) turbepoliitika – VKE, et määratleda, rakendada ja tõendada oma baastaseme nõudeid.
Turvaline baastase ei ole pelgalt kõvendamise kontrollnimekiri. See on tõend, et organisatsioon teab, milline turvalisus välja näeb, rakendab seda järjepidevalt ja suudab seda olulisel hetkel tõendada.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
