Turvalliset peruskonfiguraatiot NIS2-direktiivin ja DORA-asetuksen vaatimuksiin

Perjantai-iltapäivän virheellinen konfiguraatio, josta tuli hallituksen ongelma

Perjantaina klo 16.40 fintech-alustan tekninen vetäjä hyväksyi muutoksen, joka näytti rutiininomaiselta palomuurimuutokselta. Väliaikainen sääntö avattiin maksuanalytiikkatoimittajan integraation vianmääritystä varten. Tiketissä luki: ”poista testauksen jälkeen”. Testi onnistui. Sääntö jäi voimaan.

Kolme viikkoa myöhemmin ulkoinen skannaus löysi internetiin avoimen hallintaliittymän. Palvelin oli paikattu. MFA oli käytössä tavallisille käyttäjille. Haavoittuvuusskanneri ei merkinnyt kriittistä CVE:tä. Järjestelmä ei silti ollut turvallinen, koska sen konfiguraatio oli poikennut organisaation hyväksytystä kovennetusta tilasta.

Maanantaiaamuun mennessä tietoturvajohtajalla oli neljä keskustelua käynnissä rinnakkain:

1. Sääntelyviranomainen halusi tietää, oliko toiminnan häiriönsietokykyyn kohdistunut vaikutuksia.
2. Tietosuojavastaava halusi tietää, oliko henkilötietoja altistunut.
3. Hallitus halusi tietää, miksi ”väliaikaisia” muutoksia ei havaittu.
4. ISO/IEC 27001:2022 -standardin sisäinen auditoija halusi näyttöä siitä, että turvalliset peruskonfiguraatiot oli määritelty, hyväksytty, toteutettu ja otettu valvontaan.

Tässä kohtaa monet tietoturvaohjelmat kohtaavat epämukavan totuuden. Turvallinen konfigurointi ei ole vain tekninen koventamisen tarkistuslista. Vuonna 2026 turvalliset peruskonfiguraatiot ovat hallinnointikysymys, kyberhygieniakysymys, ICT-riskikysymys, auditointinäyttöön liittyvä kysymys ja hallituksen vastuun osoittamisen kannalta olennainen kysymys.

Sama ongelma toistuu eri muodossa monissa säännellyissä organisaatioissa. Maria, kasvavan B2B-maksunkäsittelijän tietoturvajohtaja, työskentelee vahvojen insinöörien, paikattujen järjestelmien ja pilven parhaiden käytäntöjen kanssa. NIS2- ja DORA-valmiusarviointi nostaa kuitenkin esiin yhden punaisen havainnon: formalisoitujen turvallisten peruskonfiguraatioiden puuttumisen. Hänen tiiminsä osaa koventaa palvelimet, mutta suuri osa osaamisesta on insinöörien päässä, ei hyväksytyissä standardeissa, automatisoiduissa tarkastuksissa tai näyttöpaketeissa.

Tätä aukkoa ei voi enää uskottavasti puolustaa. NIS2 edellyttää, että johtoelimet hyväksyvät kyberturvallisuusriskien hallintatoimenpiteet ja valvovat niitä. DORA edellyttää dokumentoitua ICT-riskienhallintakehystä ja häiriönsietokykyisiä ICT-toimintoja. GDPR edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä. ISO/IEC 27001:2022 edellyttää riskiperusteista hallintakeinojen valintaa, toteutusta, seurantaa, auditointia ja jatkuvaa parantamista.

Turvalliset peruskonfiguraatiot yhdistävät nämä velvoitteet yhdeksi käytännön kontrollijärjestelmäksi: määrittele perustaso, osoita omistajuus, toteuta se käyttöoikeuksien myöntämisen ja järjestelmien käyttöönoton yhteydessä, hallinnoi poikkeuksia, havaitse konfiguraatiopoikkeamat, tuota näyttö ja paranna auditointien tai poikkeamien jälkeen.

Kuten Clarysecin Zenith Blueprint: auditoijan 30-vaiheinen tiekartta kuvaa Controls in Action -vaiheen vaiheessa 19, Technological Controls I:

”Monet tietoturvaloukkaukset eivät johdu ohjelmistovirheistä vaan huonoista konfiguraatiovalinnoista. Oletussalasanat jätetään vaihtamatta, turvattomia palveluja otetaan käyttöön, tarpeettomia portteja jätetään avoimiksi tai järjestelmiä altistetaan internetiin ilman perustetta.”

Tämä lause kiteyttää, miksi turvalliset peruskonfiguraatiot ovat nyt keskeinen häiriönsietokyvyn hallintakeino. Ne määrittävät, mitä turvallinen tarkoittaa, ennen kuin auditoija, sääntelyviranomainen, asiakas tai hyökkääjä kysyy sitä.

Mitä turvallinen peruskonfiguraatio todella tarkoittaa

Turvallinen peruskonfiguraatio on hyväksytty, dokumentoitu ja toistettavissa oleva joukko tietoturva-asetuksia tietylle järjestelmätyypille. Se voi koskea Windows-palvelimia, Linux-isäntiä, verkkolaitteita, SaaS-tenant-ympäristöjä, pilvitallennusta, Kubernetes-klustereita, tietokantoja, palomuureja, päätelaitteita, identiteettialustoja, IoT-laitteita ja operatiivista teknologiaa.

Vahva perustaso vastaa käytännön kysymyksiin:

• Mitkä palvelut poistetaan oletusarvoisesti käytöstä?
• Mitkä portit voidaan altistaa ulkoisesti?
• Mitkä todennus- ja MFA-asetukset ovat pakollisia?
• Mitkä lokitusasetukset on otettava käyttöön?
• Mitä salausasetuksia edellytetään?
• Mitkä hallintaliittymät on rajoitettava?
• Mitkä pilviresurssit voivat olla julkisia ja kenen hyväksynnällä?
• Mitkä poikkeamat edellyttävät riskin hyväksymistä?
• Kuinka usein konfiguraatiopoikkeamat tarkastetaan?
• Mikä näyttö osoittaa, että perustaso toimii?

Yleisin epäonnistuminen on se, että perustasoja käsitellään insinöörien mieltymyksinä eikä hallittuina kontrolleina. Linux-ylläpitäjän tarkistuslista, pilviarkkitehdin wiki-sivu ja verkkoinsinöörin palomuurikäytäntö voivat kaikki olla hyödyllisiä, mutta niistä tulee auditoitavia vasta, kun ne on hyväksytty, kytketty riskeihin, sovellettu johdonmukaisesti ja otettu valvontaan.

Siksi ISO/IEC 27001:2022 on niin hyödyllinen ankkuri. Kohdat 4.1–4.3 edellyttävät, että organisaatiot ymmärtävät sisäiset ja ulkoiset tekijät, sidosryhmät ja ISMS:n soveltamisalan, mukaan lukien lakisääteiset, sääntelyyn liittyvät, sopimusperusteiset ja kolmansien osapuolten vaatimukset. Kohdat 6.1.2 ja 6.1.3 edellyttävät tietoturvariskien arviointia, riskien käsittelyä, hallintakeinojen valintaa, soveltuvuuslausuntoa ja riskinomistajan hyväksyntää. Kohdat 8.2 ja 8.3 edellyttävät, että riskien arvioinnit ja riskien käsittely toistetaan suunnitelluin väliajoin tai merkittävien muutosten jälkeen.

Liite A tekee teknisestä odotuksesta konkreettisen hallintakeinon A.8.9 Configuration management kautta. Sitä tukevat omaisuusluettelo, haavoittuvuuksien hallinta, muutoksenhallinta, lokitus, valvonta, pääsynhallinta, kryptografia, pilvipalvelujen käyttö ja dokumentoidut käyttömenettelyt.

Tuloksena on yksinkertainen mutta vahva hallinnointilinjaus: jos organisaatio ei pysty osoittamaan, mitä turvallinen tarkoittaa kunkin keskeisen järjestelmätyypin osalta, se ei voi uskottavasti todentaa kyberhygieniaa NIS2:n nojalla, ICT-riskienhallintaa DORA:n nojalla, osoitusvelvollisuutta GDPR:n nojalla tai kontrollien tehokkuutta ISO/IEC 27001:2022 -standardin nojalla.

Miksi NIS2, DORA ja GDPR tekevät perustasoista välttämättömiä

NIS2, DORA ja GDPR käyttävät eri kieltä, mutta ne johtavat samaan operatiiviseen vaatimukseen: järjestelmät on konfiguroitava turvallisesti, niitä on valvottava jatkuvasti ja niitä on hallittava vastuutetun riskienhallinnan kautta.

NIS2 Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuusriskien hallintatoimenpiteet, valvovat niiden toteutusta ja saavat kyberturvallisuuskoulutusta. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä. Turvalliset peruskonfiguraatiot tukevat Article 21(2)(a) -kohdan riskianalyysiä ja tietojärjestelmien turvallisuutta koskevia politiikkoja, Article 21(2)(e) -kohdan verkko- ja tietojärjestelmien hankinnan, kehityksen ja ylläpidon turvallisuutta, mukaan lukien haavoittuvuuksien käsittely, Article 21(2)(f) -kohdan vaikuttavuuden arvioinnin politiikkoja ja menettelyjä, Article 21(2)(g) -kohdan perustason kyberhygieniaa ja kyberturvallisuuskoulutusta, Article 21(2)(h) -kohdan kryptografiaa, Article 21(2)(i) -kohdan pääsynhallintaa ja omaisuudenhallintaa sekä Article 21(2)(j) -kohdan monivaiheista todennusta ja turvallista viestintää.

DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se toimii sen soveltamisalaan kuuluvien finanssialan toimijoiden toimialakohtaisena digitaalisen häiriönsietokyvyn sääntökirjana. Articles 5 and 6 edellyttävät hallinnointia ja dokumentoitua ICT-riskienhallintakehystä. Article 8 edellyttää ICT-omaisuuserien, tietovarojen, ICT-tuettujen liiketoimintatoimintojen ja riippuvuuksien tunnistamista. Article 9 edellyttää suojaus- ja ennaltaehkäisytoimenpiteitä, mukaan lukien ICT-järjestelmien tietoturvapolitiikat, menettelyt, protokollat ja työkalut, turvallinen tiedonsiirto, pääsynhallinta, vahva tunnistautuminen, kryptografisten avainten suojaus, muutoksenhallinta, paikkaus ja päivitykset. Articles 10 to 14 laajentavat mallin havaitsemiseen, reagointiin, toipumiseen, varmuuskopiointiin, palautukseen, oppimiseen ja viestintään.

GDPR lisää tietosuojanäkökulman. Articles 5 and 32 edellyttävät eheyttä, luottamuksellisuutta, käsittelyn turvallisuutta ja osoitusvelvollisuutta asianmukaisten teknisten ja organisatoristen toimenpiteiden avulla. Julkiset pilvitallennussäiliöt, liikaa altistetut tietokannat, turvattomat oletusasetukset ja liialliset ylläpito-oikeudet eivät ole vain infrastruktuurin heikkouksia. Ne voivat muodostua henkilötietojen suojaan liittyviksi epäonnistumisiksi.

Yksi turvallisten peruskonfiguraatioiden ohjelma voi tukea kaikkia kolmea sääntelykokonaisuutta ilman päällekkäisiä näyttövirtoja.

Clarysecin perustasomalli: politiikka, menettely ja alustasta saatava näyttö

Clarysec käsittelee turvallista konfigurointia toistettavana kontrollijärjestelmänä, ei kertaluonteisena koventamisprojektina. Perustaso on valtuutettava politiikalla, vietävä menettelyihin, toteutettava teknisillä kontrolleilla ja todennettava näytöllä.

Tietoturvapolitiikka asettaa tämän odotuksen organisaatiotasolla:

”Organisaation on ylläpidettävä vähimmäiskontrolliperustasoa, joka johdetaan ISO/IEC 27001 liite A:sta ja jota täydennetään soveltuvin osin ISO/IEC 27002:n, NIST SP 800-53:n ja COBIT 2019:n kontrolleilla.”
Kohdasta ”Riskienkäsittely ja poikkeukset”, politiikan lauseke 7.2.1.

Tämä lauseke estää konfiguraatioiden koventamista muuttumasta henkilökohtaisten mieltymysten kokoelmaksi. Se ankkuroi vähimmäiskontrolliperustason tunnustettuihin viitekehyksiin.

Pilviympäristöjen osalta Pilvipalvelujen käyttöpolitiikka täsmentää vaatimusta:

”Kaikkien pilviympäristöjen on noudatettava dokumentoitua peruskonfiguraatiota, jonka pilviturvallisuusarkkitehti on hyväksynyt.”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.3.1.

Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka muuttaa perustason valvottavaksi kontrolliksi:

”Automaattiset työkalut on otettava käyttöön konfiguraation vaatimustenmukaisuuden, haavoittuvuuksien hallinnan, paikkaustilan ja etuoikeutettujen käyttöoikeuksien valvomiseksi.”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.4.1.

Konfiguraatio on myös erottamaton osa haavoittuvuuksien ja korjauspäivitysten hallintaa. Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka toteaa:

”Haavoittuvuuksien korjaamisen on oltava yhdenmukaista peruskonfiguraation ja järjestelmien koventamista koskevien standardien kanssa.”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.4.1.

Tällä on merkitystä. Järjestelmä voi olla paikattu ja silti turvaton, jos SMBv1 on käytössä, hallintaliittymät ovat altistettuja, lokitus on poissa käytöstä tai heikot todennusasetukset ovat edelleen voimassa. Zenith Controls: yhteensopivuuden poikkileikkaava opas käsittelee konfiguraationhallintaa ennaltaehkäisevänä kontrollina, joka suojaa luottamuksellisuutta, eheyttä ja saatavuutta ja jonka operatiivinen kyvykkyys on turvallinen konfigurointi. Zenith Controls selittää myös konfiguraationhallinnan ja haavoittuvuuksien hallinnan välisen riippuvuuden:

”Haavoittuvuuksien hallinta riippuu tunnetuista konfiguraatioista. Ilman määriteltyä perustasoa on mahdotonta varmistaa, että korjauspäivitykset asennetaan johdonmukaisesti.”

Tämä on näyttökertomus, jota auditoijat ja sääntelyviranomaiset odottavat yhä useammin: kontrollijärjestelmä, ei irrallisia teknisiä tehtäviä.

ISO/IEC 27001:2022 A.8.9:n kartoitus sitä tukeviin hallintakeinoihin

ISO/IEC 27001:2022 -standardin liitteen A hallintakeino A.8.9 Configuration management on ankkuri, mutta sitä ei pidä käsitellä pienenä erillisenä asiakirjana. Se riippuu laajemmasta kontrolliperheestä.

Tämän kontrollien välisen suhteen vuoksi Clarysec suosittelee turvallisen konfiguroinnin hallintaa ISMS-kyvykkyytenä, jolla on omistajat, näyttö, mittarit ja johdon raportointi.

Laajempi kartoitus auttaa kääntämään saman perustaso-ohjelman muihin viitekehyksiin.

Käytännöllinen perustasorakenne, jonka voit toteuttaa tässä kuussa

Yleisin virhe on yrittää kirjoittaa täydellinen 80-sivuinen koventamisstandardi ennen minkään soveltamista. Aloita vähimmäistasoisesta mutta auditoitavasta perustasosta jokaiselle keskeiselle teknologiaperheelle ja kypsytä sitä automaation ja katselmoinnin avulla.

Pilvitallennuksen perustason ensimmäinen versio voi sisältää oletusarvoisesti poistetun julkisen pääsyn, käytössä olevan lepotilassa olevien tietojen salauksen, käytössä olevan käytön lokituksen, hallinnollisen pääsyn rajoittamisen hyväksyttyihin ryhmiin, MFA-vaatimuksen etuoikeutetulle konsolikäytölle, versionhallinnan silloin kun palautusvaatimukset sitä edellyttävät, replikoinnin rajoittamisen hyväksytyille alueille ja muutosten tekemisen vain hyväksyttyjen infrastructure-as-code-putkien kautta.

Maksunkäsittelyä tukevan Windows Server 2022 -perustason ensimmäinen versio voi sisältää SMBv1:n poistamisen käytöstä, ei-välttämättömien palvelujen poistamisen käytöstä, RDP:n rajoittamisen kovennetulle hyppypalvelimelle, Windows Defender Firewallin käyttöönoton oletusarvoisen eston säännöillä, paikallisten ylläpitäjätilien hallinnan, tapahtumalokien välittämisen SIEMiin, päätelaitesuojauksen käyttöönoton ja hallinnollisten muutosten kytkemisen hyväksyttyihin tiketteihin.

Rakenna jokaiselle perustasolle pieni näyttöpaketti:

1. Hyväksytty perustasoasiakirja.
2. Kuvakaappaus tai viety politiikka, joka osoittaa sovelletun konfiguraation.
3. Luettelo omaisuuseristä, joita perustaso koskee.
4. Muutostiketti, joka osoittaa, miten päivitykset hyväksytään.
5. Konfiguraation vaatimustenmukaisuusraportti tai manuaalisen katselmoinnin tallenne.

Tämä vastaa suoraan Zenith Blueprintin Controls in Action -vaiheen vaihetta 19, jossa Clarysec neuvoo organisaatioita laatimaan konfiguraation tarkistuslistat keskeisille järjestelmätyypeille, soveltamaan asetuksia johdonmukaisesti käyttöönotossa automaation avulla aina kun mahdollista ja auditoimaan käyttöönotettuja järjestelmiä säännöllisesti. Blueprint antaa myös käytännön auditointimenetelmän:

”Valitse muutama edustava järjestelmä (esim. yksi palvelin, yksi kytkin, yksi loppukäyttäjän PC) ja validoi, että niiden konfiguraatio vastaa turvallista perustasoasi. Dokumentoi poikkeamat ja korjaavat toimenpiteet.”

Pk-yrityksille edustava otanta on usein nopein reitti epämuodollisesta koventamisesta valmiuteen osoittaa vaatimustenmukaisuus.

Pk-yritysten koventamisesimerkit, jotka vähentävät riskiä nopeasti

Turvallinen konfigurointi ei ole vain suuryritysten pilvikysymys. Pk-yritykset saavat usein suurimman riskin pienenemisen muutamasta selkeästä perustasosäännöstä.

Verkkoturvallisuuspolitiikka – pk-yritys toteaa:

”Vain välttämättömät portit (esim. HTTPS, VPN) voidaan altistaa julkiselle internetille; kaikki muut on suljettava tai suodatettava”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.3.

Se edellyttää myös muutosten kurinalaisuutta:

”Kaikkien verkkokonfiguraatioiden muutosten (palomuurisäännöt, kytkinten ACL:t, reititystaulut) on noudatettava dokumentoitua muutoksenhallintaprosessia”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.9.1.

Lisäksi se määrittää katselmointitiheyden:

”IT-tukipalveluntarjoajan on tehtävä vuosittainen katselmointi palomuurisäännöistä, verkkoarkkitehtuurista ja langattomista konfiguraatioista”
Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.6.1.

Päätelaitteiden perustasot tarvitsevat yhtä paljon huomiota. Clarysecin Päätelaitesuojaus ja haittaohjelmapolitiikka – pk-yritys toteaa:

”Laitteiden on poistettava käytöstä vanhentuneet protokollat (esim. SMBv1), joita haittaohjelmat voivat hyväksikäyttää”
Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.2.1.3.

IoT- ja OT-ympäristöissä turvattomat oletusasetukset ovat toistuva altistus. Esineiden internetin (IoT) ja operatiivisen teknologian (OT) turvallisuuspolitiikka – pk-yritys toteaa:

”Oletus- tai kovakoodatut salasanat on vaihdettava ennen laitteiden aktivointia”
Kohdasta ”Hallinnointivaatimukset”, politiikan lauseke 5.3.2.

Nämä politiikkalausekkeet eivät ole abstrakteja kannanottoja. Ne ovat perustasovaatimuksia, jotka voidaan testata, todentaa näytöllä ja valvoa. Pk-yritykselle, joka valmistautuu asiakkaan huolellisuusarviointiin, NIS2-toimittajakatselmuksiin, kybervakuutukseen tai ISO/IEC 27001:2022 -sertifiointiin, ne tuottavat välitöntä arvoa.

Poikkeusten käsittely: kontrolli, joka erottaa kypsyyden paperityöstä

Jokaisessa perustasossa on poikkeuksia. Legacy-sovellus voi edellyttää vanhaa protokollaa. Toimittajan laite ei ehkä tue ensisijaista salausasetusta. Väliaikainen palomuurin avaus voi olla tarpeen migraation vuoksi. Kysymys ei ole siitä, onko poikkeuksia. Kysymys on siitä, hallitaanko niitä.

Kypsä poikkeuskirjaus sisältää:

• Rikottavan perustasovaatimuksen.
• Liiketoimintaperusteen.
• Vaikutuksen kohteena olevan omaisuuserän ja omistajan.
• Riskien arvioinnin.
• Kompensoivat hallintakeinot.
• Hyväksyntävaltuuden.
• Päättymispäivän.
• Seurantavaatimuksen.
• Korjaussuunnitelman.

Tässä ISO/IEC 27001:2022 -standardin riskien käsittely ja DORA:n suhteellisuusperiaate toimivat yhdessä. ISO/IEC 27001:2022 edellyttää, että kontrollipäätökset perustellaan riskien arvioinnin, riskien käsittelyn, soveltuvuuslausunnon ja riskinomistajan hyväksynnän kautta. DORA sallii oikeasuhtaisen toteutuksen koon, riskiprofiilin sekä palvelujen luonteen, laajuuden ja monimutkaisuuden perusteella, mutta edellyttää silti dokumentoitua ICT-riskien hallinnointia, valvontaa, jatkuvuutta, testausta ja tietoisuutta.

Suhteellisuus ei ole lupa ohittaa perustasoja. Se on vaatimus mitoittaa ne järkevästi.

Mikroyritykselle tai pienemmälle finanssialan toimijalle yksinkertaistetussa ICT-riskikehyksessä perustaso voi olla tiivis ja perustua manuaaliseen otantaan. Suuremmalle finanssialan toimijalle sama osa-alue edellyttää todennäköisesti automatisoituja konfiguraatiotarkastuksia, sisäisen tarkastuksen osallistumista, vuosittaista testausta ja raportointia johtoelimelle.

Muutoksenhallintapolitiikka muistuttaa organisaatioita myös seuraamaan:

”Poikkeama konfiguraatiossa tai tietojen muuttaminen hyväksyttyjen muutosten jälkeen”
Kohdasta ”Soveltaminen ja vaatimustenmukaisuus”, politiikan lauseke 8.1.2.3.

Tämä ilmaus kytkee muutoksenhallinnan konfiguraatiopoikkeaman havaitsemiseen. Muutos voi olla hyväksytty ja silti aiheuttaa riskin, jos toteutettu tila poikkeaa hyväksytystä tilasta tai jos väliaikainen asetus jää voimaan muutosikkunan sulkeuduttua.

Yhden näyttöketjun rakentaminen monia vaatimustenmukaisuusvelvoitteita varten

Turvallisen peruskonfiguraation ei pidä luoda viittä erillistä vaatimustenmukaisuustyövirtaa. Clarysecin malli käyttää yhtä näyttöketjua, joka kartoitetaan useisiin velvoitteisiin.

Avain on jäljitettävyys. Zenith Blueprintin Audit, Review and Improvement -vaiheen vaihe 24 ohjeistaa organisaatioita päivittämään soveltuvuuslausunnon ja ristiinvarmistamaan sen riskienkäsittelysuunnitelman kanssa. Jos kontrolli on sovellettavissa, tarvitset perustelun. Perustelun tulee kytkeytyä riskiin, lakisääteiseen velvoitteeseen, sopimusvaatimukseen tai liiketoimintatarpeeseen.

Turvallisen konfiguroinnin osalta A.8.9:n SoA-merkinnän tulisi viitata turvallisen konfiguroinnin perustasostandardiin, katettuihin omaisuuseräluokkiin, perustason omistajiin, muutoksenhallintamenettelyyn, valvontamenetelmään, poikkeusprosessiin, katselmointitiheyteen ja poikkivaatimuksiin, kuten NIS2 Article 21, DORA Articles 6, 8 and 9, GDPR Article 32 ja asiakassitoumukset.

Miten auditoijat testaavat turvallisia peruskonfiguraatioita

Turvallinen konfigurointi on auditoijille houkutteleva kohde, koska siitä syntyy runsaasti näyttöä. Sitä voidaan testata asiakirjojen, haastattelujen, otannan ja teknisen tarkastuksen avulla.

Käytännön kysymykset ovat ennakoitavissa:

• Käytättekö koventamisen tarkistuslistaa uusien palvelinten asennuksessa?
• Miten estätte turvattomien palvelujen, kuten Telnetin, suorittamisen reitittimissä?
• Ovatko pilvitallennusresurssit oletusarvoisesti yksityisiä?
• Kuka voi hyväksyä poikkeaman perustasosta?
• Miten havaitsette konfiguraatiopoikkeaman muutoksen jälkeen?
• Voitteko näyttää tuoreen konfiguraatiokatselmoinnin?
• Voitteko osoittaa, että havaittu poikkeama korjattiin?
• Varmuuskopioidaanko ja versioidaanko verkko- ja pilvikonfiguraatiot?
• Onko palautusmenettelyt dokumentoitu ja testattu?

Vahvimmat organisaatiot ylläpitävät perustason näyttöpakettia jokaiselle keskeiselle järjestelmäluokalle. Se lyhentää auditointeja, parantaa vastauksia asiakkaiden huolellisuusarviointeihin ja auttaa johtoa ymmärtämään kontrollien todellisen suorituskyvyn.

Muuta konfiguraatiopoikkeama hallitustason kyberhygieniamittariksi

Hallitus ei tarvitse jokaista palomuurisääntöä. Sen on kuitenkin tiedettävä, paraneeko vai heikkeneekö kyberhygienia.

Hyödyllinen turvallisen konfiguroinnin hallintanäkymä sisältää:

• Prosenttiosuus omaisuuseristä, jotka on kartoitettu hyväksyttyyn perustasoon.
• Prosenttiosuus omaisuuseristä, jotka läpäisevät perustasotarkastukset.
• Kriittisten perustasopoikkeamien määrä.
• Avoimien poikkeamien keskimääräinen ikä.
• Vanhentuneiden poikkeusten määrä.
• Havaittujen luvattomien konfiguraatiomuutosten määrä.
• Prosenttiosuus etuoikeutetuista konfiguraatiomuutoksista, joilla on hyväksytty tiketti.
• Julkisen pilvialtistuksen poikkeukset.
• Perustasojen katselmointitila teknologiaperheittäin.

Nämä mittarit tukevat ISO/IEC 27001:2022 -standardin suorituskyvyn arviointia, NIS2:n johdon valvontaa ja DORA:n ICT-riskiraportointia. Ne kytkeytyvät luontevasti myös NIST CSF 2.0:n hallinnointituloksiin ja COBIT 2019:n seuranta- ja vaatimustenmukaisuustavoitteisiin.

Yksinkertainen johdon sääntö auttaa: mikään kriittinen järjestelmä ei siirry tuotantoon ilman perustason näyttöä. Tämä voidaan toteuttaa muutoksenhallinnan, CI/CD-porttien, pilvipolitiikkatarkastusten, infrastructure-as-code-katselmoinnin, MDM-vaatimustenmukaisuuden, GPO-soveltamisen tai verkkokonfiguraation katselmoinnin kautta. Kypsyystaso voi vaihdella, mutta kontrollilogiikan ei tulisi vaihdella.

90 päivän pelikirja turvallisille peruskonfiguraatioille

Jos aloitat tyhjästä, älä yritä ratkaista kaikkia konfiguraatio-ongelmia kerralla. Käytä 90 päivän suunnitelmaa.

Päivät 1–30: määrittele vähimmäisperustaso

Tunnista kriittiset omaisuuseräluokat. Osoita jokaiselle tekninen omistaja, riskinomistaja ja hyväksyntävaltuus. Luo ensimmäinen perustaso asetuksille, jotka ovat olennaisimpia kiristyshaittaohjelmien sietokyvyn, pilvialtistuksen, etuoikeutetun pääsyn, lokituksen, salauksen ja tietosuojan kannalta.

Luo perustasorekisteri ja kartoita se ISMS:n soveltamisalaan, riskirekisteriin ja soveltuvuuslausuntoon. Jos NIS2 koskee sinua, selvitä, oletko keskeinen vai tärkeä toimija, tai odottavatko asiakkaat NIS2:n mukaista kyberhygieniaa. Jos olet DORA:n alainen finanssialan toimija, tunnista, mitkä ICT-omaisuuserät tukevat kriittisiä tai tärkeitä toimintoja. Jos käsittelet henkilötietoja, kartoita järjestelmät GDPR:n käsittelytoimiin ja tietoluokkiin.

Päivät 31–60: sovella perustaso ja kerää näyttö

Sovella perustasoa korkean riskin järjestelmien otokseen. Käytä automaatiota aina kun mahdollista, mutta älä odota täydellistä työkalustoa. Vie konfiguraatiot, ota kuvakaappauksia, tallenna politiikka-asetukset ja kirjaa muutostiketit.

Luo jokaiselle poikkeukselle riskikirjaus, jossa on päättymispäivä. Luo jokaiselle poikkeamalle korjaustiketti.

Päivät 61–90: valvo, raportoi ja paranna

Tee konfiguraatiokatselmointi. Ota otokseen yksi palvelin, yksi päätelaite, yksi verkkolaite ja yksi pilviympäristö. Vertaa todellisia asetuksia hyväksyttyyn perustasoon. Dokumentoi poikkeamat ja korjaavat toimenpiteet.

Raportoi perustason noudattaminen johdolle. Päivitä soveltuvuuslausunto ja riskienkäsittelysuunnitelma. Syötä toistuvat poikkeamat juurisyyanalyysiin. Jos virheellinen konfiguraatio aiheutti poikkeaman tai vaikutti siihen, päivitä asiaankuuluva perustaso opittujen asioiden osana.

Tämä antaa auditoijille testattavaa, sääntelyviranomaisille ymmärrettävää ja johdolle hallinnoitavaa.

Lopuksi: turvallinen konfigurointi on todennettua kyberhygieniaa

NIS2 käyttää kyberturvallisuusriskien hallintatoimenpiteiden ja perustason kyberhygienian kieltä. DORA käyttää ICT-riskin, häiriönsietokyvyn, valvonnan, jatkuvuuden ja testauksen kieltä. GDPR käyttää asianmukaisten toimenpiteiden ja osoitusvelvollisuuden kieltä. ISO/IEC 27001:2022 käyttää riskien käsittelyn, hallintakeinojen, dokumentoidun tiedon, suorituskyvyn arvioinnin ja jatkuvan parantamisen kieltä.

Turvalliset peruskonfiguraatiot yhdistävät ne kaikki.

Ne osoittavat, ettei järjestelmiä oteta käyttöön turvattomilla oletusasetuksilla. Ne osoittavat, että muutokset ovat hallittuja. Ne osoittavat, että konfiguraatiopoikkeamat havaitaan. Ne osoittavat, että poikkeukset hyväksytään riskiperusteisesti. Ne osoittavat, että näyttö on olemassa ennen kuin auditoija sitä pyytää.

Tärkeintä on, että ne vähentävät todellista operatiivista riskiä. Perjantai-iltapäivän palomuurisääntö, julkinen pilvitallennussäiliö, unohtunut SMBv1-asetus, oletusarvoinen IoT-salasana ja lokittamaton hallintakonsoli eivät ole teoreettisia auditointihavaintoja. Ne ovat käytännön vikapisteitä.

Clarysec auttaa organisaatioita muuttamaan nämä vikapisteet hallituiksi, valvotuiksi ja auditoitaviksi perustasoiksi.

Seuraavat vaiheet

Jos organisaatiosi tarvitsee näyttöä turvallisesta konfiguroinnista ISO/IEC 27001:2022 -standardia, NIS2:n kyberhygieniaa, DORA:n ICT-riskienhallintaa, GDPR:n osoitusvelvollisuutta tai asiakkaiden varmentamista varten, aloita Clarysecin työkalupakista:

• Käytä Zenith Blueprint: auditoijan 30-vaiheinen tiekartta konfiguraationhallinnan toteuttamiseen Controls in Action -vaiheen vaiheessa 19 ja sen validointiin Audit, Review and Improvement -vaiheen vaiheessa 24.
• Käytä Zenith Controls: yhteensopivuuden poikkileikkaava opas kartoittaaksesi konfiguraationhallinnan sitä tukeviin ISO/IEC 27001:2022 -hallintakeinoihin, NIS2:een, DORA:an, GDPR:ään, NIST SP 800-53:een, COBIT 2019:ään ja auditointimenetelmiin.
• Käytä Clarysec-politiikkoja, kuten Tietoturvapolitiikka, Pilvipalvelujen käyttöpolitiikka, Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka, Verkkoturvallisuuspolitiikka – pk-yritys, Päätelaitesuojaus ja haittaohjelmapolitiikka – pk-yritys ja Esineiden internetin (IoT) ja operatiivisen teknologian (OT) turvallisuuspolitiikka – pk-yritys määritelläksesi, soveltaaksesi ja todentaaksesi perustasovaatimuksesi.

Turvallinen perustaso ei ole vain koventamisen tarkistuslista. Se on näyttö siitä, että organisaatiosi tietää, miltä turvallinen näyttää, soveltaa sitä johdonmukaisesti ja pystyy osoittamaan sen silloin, kun sillä on merkitystä.