Päätelaitteiden haittaohjelmien torjunta: ISO 27001 -näyttö EU-vaatimuksia varten

On maanantai kello 07.42. Talouspäällikkö avaa toimittajan laskun sähköpostiketjusta, joka näyttää aidolta. Muutaman minuutin kuluttua päätelaitteiden havainnointikonsoli merkitsee epäilyttävän skriptin suorituksen, pysyvyyden tavoittelun ja ulospäin suuntautuvan liikenteen tuntemattomaan verkkotunnukseen. EDR-agentti eristää kannettavan automaattisesti. Kiristyshaittaohjelmaketju katkeaa ennen salauksen alkamista.

Tietoturvakontrolli toimi. Vaikeampi kysymys tulee kuitenkin seuraavaksi.

Tietoturvajohtajalta ei kysytä vain: ”Pysäytimmekö haittaohjelman?” Toimitusjohtaja ja hallitus kysyvät: ”Voimmeko osoittaa, että kyse oli suunnitellusta häiriönsietokyvystä eikä onnesta? Voimmeko osoittaa auditoijille, asiakkaille, viranomaisille ja vakuuttajille, että päätelaitesuojaus toimi tavalla, joka täyttää ISO/IEC 27001:2022:n, NIS2-kyberhygienian, DORA:n ICT-riskienhallinnan ja GDPR Article 32:n vaatimukset?”

Tämä on päätelaiteturvallisuuden keskeinen haaste vuonna 2026. Päätelaitesuojaus ei ole enää pelkkä IT-operatiivinen toiminto. Se on vaatimustenmukaisuusnäytön järjestelmä.

Yksittäinen kannettavan haittaohjelmahälytys voi muuttua ISO/IEC 27001:2022 -auditoinnin otokseksi, NIS2:n merkittävän poikkeaman arvioksi, DORA:n ICT:hen liittyväksi poikkeamatallenteeksi, GDPR:n henkilötietojen tietoturvaloukkauksen triageksi, toimittajariskikeskusteluksi ja hallituksen hallinnointikatselmukseksi. Organisaatiot, jotka hoitavat tämän hyvin, eivät vain ota EDR:ää käyttöön. Ne yhdistävät politiikan, inventaarion, tekniset kontrollit, seurannan, tietoturvapoikkeamiin reagoinnin, oikeudellisen triagen, toimittajasopimukset, mittarit ja jatkuvan parantamisen yhdeksi auditoinnissa puolustettavaksi kontrollikuvaukseksi.

Clarysec näkee saman kaavan SaaS-, fintech-, hallinnoitujen palvelujen ja säänneltyjen digitaalisten ympäristöjen parissa. Useimmilla organisaatioilla on jo vahvoja työkaluja: EDR, virustorjunta, MDM, haavoittuvuusskannerit, SIEM, sähköpostin tietoturva, verkkosuodatus, varmuuskopiointialustat ja tikettijärjestelmät. Puute ei yleensä ole teknologiassa. Puute on näytön suunnittelussa.

Tässä artikkelissa kuvataan, miten rakennetaan valmius osoittaa auditoinneissa päätelaitteiden haittaohjelmien torjunnan näyttö käyttämällä ISO/IEC 27001:2022 -standardia ISMS:n runkona, Clarysecin Päätelaitesuojaus- / haittaohjelmapolitiikkaa Päätelaitesuojaus- / haittaohjelmapolitiikka, pk-yrityksille tarkoitettua Päätelaitesuojaus - haittaohjelmapolitiikkaa Päätelaitesuojaus - haittaohjelmapolitiikka - pk-yritys, Zenith Blueprint: An Auditor’s 30-Step Roadmap -opasta Zenith Blueprint ja Zenith Controls: The Cross-Compliance Guide -opasta Zenith Controls.

Miksi päätelaitteiden haittaohjelmien torjunta on nyt hallitustason vaatimustenmukaisuuskysymys

Nykyaikainen päätelaite on kohta, jossa identiteetti, liiketoimintatiedot, käyttäjän toiminta, hyökkääjien toimintatavat ja sääntelyyn liittyvä osoitusvelvollisuus kohtaavat. Kannettavat muodostavat yhteyksiä kotiverkoista ja lentoasemilta. Kehittäjät käyttävät paikallisia työkaluja. Johto matkustaa mukanaan välimuistiin tallennettuja sähköposteja ja tiedostoja. Toimeksisaajat voivat käyttää hallittuja tai osittain hallittuja laitteita. Mobiilipuhelimet hyväksyvät MFA-kehotteita. Pilvityökuormat ja palvelimet käyttäytyvät EDR-näkökulmasta päätelaitteiden tavoin.

Zenith Blueprint -oppaassa Controls in Action -vaiheen Step 19: Technological Controls I -kohdassa Clarysec kuvaa käyttäjien päätelaitteita organisaation ”ovina ja ikkunoina”:

Käyttäjien päätelaitteet, kannettavat, älypuhelimet, tabletit, työasemat ja jopa thin client -päätteet ovat paikka, josta digitaalinen vuorovaikutus alkaa. Ne ovat järjestelmienne ovet ja ikkunat. Ja kuten missä tahansa fyysisessä rakenteessa, ne on vahvistettava, niitä on valvottava ja niitä on hallittava.

Tällä näkökulmalla on merkitystä, koska päätelaitesuojaus ei koske vain haittaohjelmien estämistä. Sen on osoitettava, että organisaatio tietää, mitä laitteita sillä on, hallinnoi niiden käyttöä, soveltaa tietoturvan perustasoja, havaitsee vaarantumisen, reagoi yhdenmukaisesti, säilyttää näytön, palauttaa toiminnan ja parantaa toimintaansa poikkeamien jälkeen.

Kypsän päätelaitteiden haittaohjelmien torjuntaohjelman on vastattava neljään auditointikysymykseen epäröimättä:

1. Tunnemmeko jokaisen päätelaitteen, joka voi käyttää liiketoimintajärjestelmiä tai henkilötietoja?
2. Onko jokainen päätelaite suojattu hyväksytyllä, keskitetysti hallitulla haittaohjelmien torjunnalla tai EDR:llä?
3. Voimmeko osoittaa konfiguraation, tarkistukset, päivitykset, hälytykset, karanteenin, eristyksen, tutkinnan ja sulkemisen?
4. Voimmeko yhdistää päätelaitetapahtumat riskien käsittelyyn, tietoturvapoikkeamiin reagointiin, sääntelyraportointiin, toimittajien valvontaan ja johdon katselmointiin?

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän, jolla näihin kysymyksiin voidaan vastata. Lausekkeet 4.1–4.4 edellyttävät, että organisaatio määrittää toimintaympäristön, sidosryhmät, lakisääteiset ja sopimusperusteiset velvoitteet, rajapinnat, riippuvuudet ja ISMS:n soveltamisalan. Päätelaitesuojausta koskeva soveltamisala ei voi pysähtyä ”yrityksen IT:hen”. Sen on huomioitava etätyö, etuoikeutetut työasemat, mobiililaitteet, pilvikäyttö, toimittajien hallinnoimat laitteet, päätelaitelokit, ulkoistetut SOC- tai MDR-palvelut ja kaikki päätelaitteet, jotka voivat vaikuttaa tietoturvallisuuteen.

Lausekkeet 5.1–5.3 tekevät johdon vastuun selväksi. Ylimmän johdon on tuettava ISMS:ää, osoitettava roolit, annettava resurssit ja varmistettava politiikkojen yhdenmukaisuus. Päätelaitteiden näkökulmasta hallitus ei voi hyväksyä kyberhygienian tavoitteita ja samalla jättää EDR-lisensoinnin, korjauspäivitysvelan, BYOD-poikkeukset tai MDR-eskaloinnin puutteet ratkaisematta.

Lausekkeet 6.1.1–6.1.3 muodostavat riskien käsittelyn moottorin. Päätelaitteiden haittaohjelmariskit on tunnistettava, arvioitava, käsiteltävä, kartoitettava liitteen A hallintakeinoihin, huomioitava soveltuvuuslausunnossa ja hyväksytettävä riskinomistajilla silloin, kun jäännösriski jää jäljelle. Lausekkeet 8.1–8.3 muuttavat riskien käsittelyn hallituiksi operaatioiksi, suunnitelluiksi muutoksiksi, säännöllisiksi tai merkittävien muutosten jälkeisiksi riskien arvioinneiksi sekä riskien käsittelyn tuloksiksi.

Auditointitarina ei ole ”asensimme EDR:n”. Auditointitarina on ”päätelaitteiden haittaohjelmariski on tunnistettu, arvioitu, käsitelty, operoitu, seurattu, testattu, todennettu näytöllä, raportoitu ja parannettu”.

Clarysecin politiikkasilta EDR-asetuksista auditointinäyttöön

Politiikka on kohta, jossa tekninen todellisuus muuttuu auditoitavaksi tarkoitukseksi. Ilman politiikkaa päätelaitteiden konfiguraatiot ovat vain työkalun asetuksia. Politiikan avulla näistä asetuksista tulee kontrollivaatimuksia.

Clarysecin yritystason Päätelaitesuojaus- / haittaohjelmapolitiikka muodostaa tämän sillan lausekkeessa 1.3:

Tämä politiikka tukee suoraan ISO/IEC 27001:2022 Clause 8.1:n ja Annex A Control 8.7:n mukaista vaatimustenmukaisuutta ja on yhdenmukainen GDPR:n, NIS2:n ja DORA:n mukaisten alueellisten kyberturvallisuusvelvoitteiden kanssa.

Tämä yksi lauseke antaa organisaatiolle suoran yhteyden päätelaiteoperaatioista ISO/IEC 27001:2022:een, NIS2:een, DORA:an ja GDPR:ään. Auditoijat voivat sen jälkeen testata, vastaako organisaation todellinen päätelaiteohjelma politiikassa annettua sitoumusta.

Sama yritystason politiikka määrittää odotetun toimintamallin Hallinnointivaatimukset-osiossa, lausekkeessa 5.2:

Kaikki päätelaitteet on rekisteröitävä keskitetysti hallittuihin haittaohjelmasuojausjärjestelmiin (esim. EDR, virustorjunta tai vastaavat alustat), joissa sovelletaan pakollista peruskonfiguraatiota.

Tämä on juuri sellainen lausuma, josta auditoijat pitävät, koska se on testattavissa. Jos ”kaikki päätelaitteet” on rekisteröitävä, näytön on osoitettava koko päätelaitejoukko, odotettu EDR-kattavuus, rekisteröinnin tila, poikkeukset, korvaavat kontrollit ja korjaustoimien eteneminen.

Pk-yrityksille Päätelaitesuojaus - haittaohjelmapolitiikka antaa suorat, operatiiviset vaatimukset. Lauseke 5.1.3 toteaa:

Kaikki päätelaitteet on kirjattava IT-omaisuusluetteloon ja linkitettävä käytössä olevaan päätelaitesuojaustyökaluun

Lauseke 5.2.1 lisää:

Kaikissa päätelaitteissa saa käyttää vain organisaation hyväksymiä virustorjunta- tai EDR-ratkaisuja (endpoint detection and response)

Lauseke 6.1.1.1 edellyttää:

Suorita reaaliaikaista virustorjunta- ja haittaohjelmien torjuntatarkistusta jatkuvasti

Ja lauseke 8.1.1 edellyttää:

Haittaohjelmatapahtumia on seurattava jatkuvasti virustorjuntakonsolin tai keskitetyn EDR-hallintanäkymän kautta

Yhdessä nämä lausekkeet muodostavat yksinkertaisen mutta vahvan näyttötestin: näytä inventaario, näytä päätelaitesuojaustyökalu, näytä hyväksytty konfiguraatio, näytä jatkuva seuranta, näytä tapahtumat, näytä tiketit ja näytä sulkeminen.

ISO/IEC 27001:2022 ja ISO/IEC 27002:2022 -päätelaitekontrollien kartoitus

Päätelaitesuojaus epäonnistuu auditoinneissa usein siksi, että tiimit käsittelevät sitä yhtenä kontrollina. Todellisuudessa päätelaitteiden haittaohjelmien torjunta perustuu useisiin toisiaan vahvistaviin kontrolleihin.

Keskeiset ISO/IEC 27002:2022 -hallintakeinot ovat A.8.1 User endpoint devices ja A.8.7 Protection against malware. Tehokas päätelaitteiden suojaus edellyttää kuitenkin myös haavoittuvuuksien hallintaa, lokitusta, seurantaa, tietoturvapoikkeamiin reagointia, varmuuskopiointia, verkkosuodatusta, siirrettävien tallennusvälineiden hallintaa, pääsyn rajoittamista, toimittajahallintaa, pilvipalvelujen hallinnointia, tietoisuutta ja liiketoiminnan jatkuvuutta.

Zenith Controls kartoittaa ISO/IEC 27002:2022 -hallintakeinon A.8.7, Protection against malware, ennalta ehkäiseväksi, havaitsevaksi ja korjaavaksi. Se tukee luottamuksellisuutta, eheyttä ja saatavuutta sekä kytkeytyy luontevasti järjestelmä- ja verkkoturvallisuuteen, tietojen suojaamiseen ja havaitsemiskyvykkyyksiin. Se osoittaa myös, että A.8.1, User endpoint devices, on ennalta ehkäisevä hallintakeino, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta omaisuudenhallinnan ja päätelaitteiden hallinnoinnin kautta.

Zenith Controls on erityisen hyödyllinen, koska se osoittaa, miten päätelaitteiden suojaus riippuu vierekkäisistä kontrolleista. Protection against malware kytkeytyy A.5.7 Threat intelligence -hallintakeinoon, koska haittaohjelmien torjunnan on mukauduttava muuttuviin toimintatapoihin. Se kytkeytyy A.8.8 Management of technical vulnerabilities -hallintakeinoon, koska haittaohjelmat hyödyntävät usein tunnettuja heikkouksia. Se kytkeytyy A.8.15 Logging- ja A.8.16 Monitoring activities -hallintakeinoihin, koska havainnot, karanteenit, tarkistukset ja päivitykset on kerättävä ja katselmoitava. Se kytkeytyy A.8.23 Web filtering -hallintakeinoon, koska haitalliset sivustot ovat edelleen yleinen tartuntareitti. Se kytkeytyy A.7.10 Storage media -hallintakeinoon, koska siirrettävät tallennusvälineet voivat tuoda haittaohjelmia, jos niitä ei hallita.

User endpoint devices kytkeytyy myös hallintakeinoihin A.5.10 Acceptable use of information and other associated assets, A.6.7 Remote working, A.8.3 Information access restriction, A.8.5 Secure authentication, A.6.3 Information security awareness, education and training sekä A.6.6 Confidentiality or non-disclosure agreements.

Yksinkertaisesti sanottuna turvallinen päätelaite ei ole vain laite, jossa on agentti. Se on politiikalla ohjattu työympäristö.

Haittaohjelmahälytyksen muuttaminen puolustettavaksi näyttöketjuksi

Palataan maanantaiaamun haittaohjelmatapahtumaan. EDR-agentti eristi kannettavan, mutta valmius osoittaa vaatimustenmukaisuus riippuu sitä seuraavasta näyttöketjusta.

Hyvä päätelaitteen haittaohjelman näyttöketju sisältää:

• Omaisuustallenteen, joka osoittaa omistajan, liiketoiminnallisen roolin, kriittisyyden, laitetyypin, käyttöjärjestelmän, tietojen käyttöprofiilin ja salauksen tilan.
• Päätelaitesuojaustallenteen, joka osoittaa EDR-agentin toimintakunnon, sovelletun politiikan, peukaloinnin eston, päivitysten tilan ja reaaliaikaisen tarkistuksen.
• Havaintotallenteen, joka osoittaa hälytystunnisteen, aikaleiman, prosessipuun, havaitsemislogiikan, vakavuuden, vaikutuksen kohteena olevat tiedostot, verkkoindikaattorit ja automatisoidut toimet.
• SIEM-tallenteen, joka korreloi DNS-, sähköposti-, identiteetti-, välityspalvelin-, pilvi- ja päätelaitetelemetrian.
• Tikettitallenteen, joka osoittaa triagen, eskaloinnin, rajaamisen, poistamisen, palautumisen, juurisyyn ja sulkemisen.
• Poikkeamapäätöksen, joka osoittaa, jäikö tapahtuma tietoturvatapahtumaksi vai muuttuiko se poikkeamaksi.
• Sääntelytriagen, joka osoittaa, arvioitiinko NIS2-, DORA- tai GDPR-kynnysarvoja.
• Opitut asiat -tallenteen, joka osoittaa politiikan hienosäädön, paikkauksen, tietoisuustoimen, toimittajatiketin tai riskirekisteripäivityksen.

Päätelaitesuojaus- / haittaohjelmapolitiikka vahvistaa tätä reagointimallia Politiikan toteutusvaatimukset -osiossa, lausekkeessa 6.3, jonka otsikko on:

Reagointi- ja rajaamistoimet

Pk-yrityksille lauseke 6.3.1.2 on vielä suorempi:

IT-tukipalveluntarjoajan on asetettava laite karanteeniin, vahvistettava tartunta ja tehtävä juurisyyanalyysi

Estetyn haittaohjelmatapahtuman ei pidä kadota konsoliin. Jos se on riittävän merkittävä havaittavaksi, se on riittävän merkittävä luokiteltavaksi, dokumentoitavaksi ja suljettavaksi.

NIS2-kyberhygienian näyttö päätelaitesuojaamisesta

NIS2 tekee perustason kyberhygieniasta hallinnointikysymyksen. Soveltamisalaan kuuluvien organisaatioiden on ymmärrettävä, kuuluvatko ne soveltamisalaan, ovatko ne keskeisiä vai tärkeitä toimijoita ja miten kansalliset täytäntöönpanovelvoitteet soveltuvat.

Päätelaitteiden haittaohjelmien torjunnan kannalta Article 21 on keskeinen säännös. Se edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä verkko- ja tietojärjestelmiin kohdistuvien riskien hallitsemiseksi sekä poikkeamien vaikutusten ehkäisemiseksi tai minimoimiseksi. Toimenpiteisiin sisältyvät riskianalyysi ja tietojärjestelmien tietoturvapolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta ja ylläpito mukaan lukien haavoittuvuuksien käsittely, vaikuttavuuden arviointi, perustason kyberhygienia ja koulutus, kryptografia, HR-turvallisuus, pääsynhallinta, omaisuudenhallinta sekä tarvittaessa MFA tai jatkuva todennus.

Päätelaitenäyttö vastaa suoraan näihin odotuksiin.

Myös NIS2 Article 23 on merkityksellinen, koska haittaohjelmasta voi tulla merkittävä poikkeama. Jos se aiheuttaa tai voisi aiheuttaa vakavan toiminnallisen häiriön, taloudellisen tappion tai huomattavaa aineellista tai aineetonta vahinkoa muille, vaiheittainen raportointi voi olla tarpeen. NIS2 sisältää varhaisvaroituksen 24 tunnin kuluessa, poikkeamailmoituksen 72 tunnin kuluessa, väliarvioita pyydettäessä sekä loppuraportin kuukauden kuluessa ilmoituksesta.

Päätelaitenäyttö tukee jokaista vaihetta. EDR-hälytys antaa ensimmäisen indikaattorin. Omaisuusluettelo tunnistaa vaikutuksen kohteena olevat palvelut ja kriittisyyden. SIEM-tiedot ja tiketit tukevat vaikutusanalyysiä. Rajaamistallenteet osoittavat toimenpiteet. Juurisyyanalyysi tukee loppuraportointia.

NIS2-valmis vastaus ei ole ”meillä on virustorjunta”. Se on ”tunnemme päätelaitteemme, sovellamme suojausta, seuraamme jatkuvasti, luokittelemme poikkeamat, koulutamme käyttäjiä, hallitsemme haavoittuvuuksia, säilytämme näytön ja raportoimme, kun kynnysarvot täyttyvät”.

DORA ICT-riskienhallinta ja päätelaitteiden haittaohjelmien torjunta

Finanssialan toimijoille DORA luo toimialakohtaisen digitaalisen toiminnallisen häiriönsietokyvyn viitekehyksen. Päätelaitteiden haittaohjelmien torjunta kytkeytyy vahvasti ICT-riskienhallintaan, poikkeamien hallintaan, testaukseen, jatkuvuuteen, palautumiseen ja ICT-kolmansien osapuolten riskiin.

DORA Article 5 asettaa vastuun ICT-riskistä hallintoelimelle. Article 6 edellyttää toimivaa, kattavaa ja dokumentoitua ICT-riskienhallinnan viitekehystä. Articles 8 ja 9 edellyttävät ICT-tuettujen liiketoimintatoimintojen, tietovarojen, ICT-omaisuuserien, riippuvuuksien, kyberuhkien, haavoittuvuuksien, konfiguraatioiden ja keskinäisten riippuvuuksien tunnistamista ja luokittelua. Ne kattavat myös suojauksen, ennaltaehkäisyn, havaitsemisen, pääsynhallinnan, vahvan tunnistautumisen, muutoksenhallinnan ja paikkauksen politiikat ja työkalut.

Articles 11 ja 12 ovat keskeisiä kiristyshaittaohjelmien häiriönsietokyvyn kannalta. Ne edellyttävät ICT-liiketoiminnan jatkuvuuspolitiikkaa, reagointi- ja palautussuunnitelmia, varmuuskopiointipolitiikkoja, palautusmenettelyjä, testausta ja eheystarkastuksia. Article 17 edellyttää ICT:hen liittyvien poikkeamien hallintaprosessia poikkeamien havaitsemiseksi, hallitsemiseksi, luokittelemiseksi, kirjaamiseksi, eskaloimiseksi, viestimiseksi ja toiminnan palauttamiseksi poikkeamien jälkeen. Article 19 luo raportointivelvoitteet merkittävistä ICT:hen liittyvistä poikkeamista. Articles 24–26 koskevat digitaalisen toiminnallisen häiriönsietokyvyn testausta. Articles 28–30 koskevat ICT-kolmansien osapuolten riskiä ja sopimusjärjestelyjä.

Finanssialan toimijalla sama haittaohjelmapoikkeama, joka osoittaa A.8.7:n toiminnan, voi samalla tuottaa DORA-valvontanäyttöä: omaisuusluokittelu, kontrollin toiminta, poikkeamien hallinta, palautumiskyvykkyys, testaushistoria, kolmannen osapuolen vastuu ja johdon valvonta.

GDPR Article 32 ja henkilötietojen tietoturvaloukkauksen triage

GDPR Article 32 edellyttää, että rekisterinpitäjät ja henkilötietojen käsittelijät toteuttavat riskiin nähden asianmukaiset tekniset ja organisatoriset toimenpiteet. Näihin toimenpiteisiin kuuluvat käsittelyjärjestelmien ja -palvelujen luottamuksellisuus, eheys, saatavuus ja häiriönsietokyky, kyky palauttaa henkilötietojen saatavuus ja pääsy tietoihin sekä tietoturvatoimenpiteiden säännöllinen testaus, arviointi ja tarkastelu.

Päätelaitteen haittaohjelmasta tulee GDPR-näyttöä, kun päätelaite voi käyttää henkilötietoja: asiakastietueita, tukitikettejä, HR-tiedostoja, vientitiedostoja, maksuihin liittyviä tietoja, terveystietoja, erityisiin henkilötietoryhmiin kuuluvia tietoja, todennuslokeja tai henkilötietoja sisältäviä pilvisovelluksia.

Tietosuojakysymys on tosiseikkakohtainen. Suoritettiinko haittaohjelma? Pääsikö se tiedostoihin? Kaappasiko se tunnistetietoja? Varastettiinko tokenit? Siirrettiinkö tietoja luvattomasti? Oliko päätelaite salattu? Poistettiinko käyttäjätili käytöstä? Peruutettiinko istunnot? Oliko lokit käytettävissä? Tunnistettiinko vaikutuksen kohteena olevat henkilötiedot? Arvioitiinko riski luonnollisille henkilöille?

Päätelaitetelemetria on usein ainoa tapa vastata näihin kysymyksiin uskottavasti.

GDPR-valmiin päätelaitenäyttöpaketin tulisi yhdistää tietojen luokittelu ja käsittelytallenteet, päätelaitteen käyttöpolut, salaus, pääsyn rajoittaminen, EDR-telemetria, SIEM-lokit, tietojen luvattoman siirron analyysi, tunnistetietojen nollaustoimet, palautustallenteet, oikeudellinen tarkastelu, tietoturvaloukkauspäätökset ja opitut asiat.

Tietosuojatiimien tulisi osallistua päätelaitteiden poikkeamapelikirjojen suunnitteluun. Jos vasta haittaohjelmapoikkeaman jälkeen kysytään, vaikuttiko tapahtuma henkilötietoihin, syntyy vältettävissä oleva osoitusvelvollisuusriski.

Rakenna 30 minuutin päätelaitteen haittaohjelman näyttöpaketti

Valitse ennen seuraavaa auditointia yksi päätelaitteen haittaohjelmahavainto viimeisten 90 päivän ajalta, vaikka sen vakavuus olisi ollut alhainen tai kyse olisi estetystä testitiedostosta. Rakenna näyttöpaketti ikään kuin auditoija olisi valinnut sen otokseksi.

Käytä Zenith Blueprint -oppaan Controls in Action -vaiheen Step 19:ää katselmointiohjeena. Step 19 ohjaa tiimejä katselmoimaan haittaohjelmasuojausstrategiaa tarkistamalla, että kaikissa päätelaitteissa on keskitetysti hallittu haittaohjelmien torjunta tai EDR asennettuna, aktiivisena ja automaattisesti päivittyvänä; että reaaliaikainen tarkistus kattaa tiedostotyypit, verkkotoiminnan ja siirrettävät tallennusvälineet; että yhdyskäytäväsuojaukset ovat käytössä; että viimeaikaiset haittaohjelmalokit tai karanteenit tutkitaan ja ratkaistaan; ja että käyttäjät saavat jatkuvaa tietojenkalastelu- ja haittaohjelmatietoisuuskoulutusta.

Kerää tämä näyttö:

1. Omaisuustallenne: laitteen nimi, sarjanumero, käyttäjä, omistaja, liiketoimintayksikkö, sijainti, laitetyyppi, käyttöjärjestelmä, kriittisyys, tietojen käyttöprofiili.
2. EDR-rekisteröinti: kuvakaappaus tai vienti, joka osoittaa, että agentti on asennettu, aktiivinen, päivitetty, politiikka on sovellettu ja peukaloinnin esto on käytössä.
3. Perustason vaatimustenmukaisuus: salaus, näytön lukitus, palomuuri, paikallisen ylläpitäjän tila, korjauspäivitystaso, kiellettyjen ohjelmistojen tila.
4. Havaintotallenne: hälytystunniste, aikaleima, havainnon nimi tai käyttäytyminen, vakavuus, prosessipuu, vaikutuksen kohteena olevat tiedostot, verkkoindikaattorit.
5. Rajaamistoimi: karanteeni, eristys, prosessin lopetus, tiedoston poisto, laitteen uudelleenasennus, tunnistetietojen nollaus.
6. Tutkintamuistiinpanot: analyytikon triage, juurisyy, tietojenkalastelureitti, verkkoreitti, hyväksikäyttöreitti, vaikutuksen kohteena olevien tietojen arviointi.
7. Poikkeamapäätös: tietoturvatapahtuma tai poikkeama, NIS2-, DORA- ja GDPR-kynnysarviointi soveltuvin osin.
8. Sulkemisnäyttö: tiketin sulkeminen, hyväksyntä, opitut asiat, tarvittaessa riskirekisterin päivitys.
9. Mittarit: havaitsemisaika, rajaamisaika, korjausaika, vastaavien hälytysten määrä, väärän positiivisen havainnon tila.
10. Parannustoimi: estetty verkkotunnus, sähköpostisäännön hienosäätö, korjauspäivityksen käyttöönotto, käyttäjän tietoisuuskoulutuksen osoittaminen, toimittajaeskalointi.

Vertaa sen jälkeen näyttöpakettia politiikkaasi. Jos yritystason politiikka sanoo, että kaikki päätelaitteet on rekisteröitävä keskitetysti hallittuun haittaohjelmasuojaukseen pakollisella perustasolla, voitko osoittaa sen? Jos pk-yrityksen politiikka sanoo, että haittaohjelmatapahtumia on seurattava jatkuvasti virustorjuntakonsolin tai keskitetyn EDR-hallintanäkymän kautta, voitko näyttää hallintanäkymän, katselmoijan, hälytyksen, tiketin ja sulkemisen?

Näin EDR-tiedoista tulee auditointinäyttöä.

Miten eri auditoijat testaavat samoja päätelaitekontrolleja

Eri varmennustiimit tarkastelevat päätelaitesuojausta eri näkökulmista. Näyttö voi olla sama, mutta kysymykset muuttuvat.

NIST CSF 2.0 on erityisen hyödyllinen johdolle suunnattuna siltakielenä. Sen GOVERN-toiminto tukee sidosryhmien odotuksia, lakisääteisiä velvoitteita, riskinottohalukkuutta, osoitusvelvollisuutta, politiikkaa, resursseja ja valvontaa. Sen operatiiviset toiminnot auttavat selittämään, miten omaisuudenhallinta, pääsynhallinta, tietosuoja, seuranta, tietoturvapoikkeamiin reagointi, rajaaminen, poistaminen, palautuminen ja viestintä toimivat yhdessä.

Clarysec-projekteissa ISO/IEC 27001:2022 tarjoaa muodollisen ISMS-rungon, Zenith Controls tarjoaa vaatimustenmukaisuuden poikkikartoituksen oppaan ja NIST CSF 2.0 tarjoaa hallitusystävällisen viestintäkerroksen.

Toimittajien hallinnoimat päätelaitepalvelut ovat osa näyttömallia

Monet organisaatiot ulkoistavat osia päätelaitteiden suojauksesta MSP-, MSSP- ja MDR-palveluntarjoajille, pilvityöpöytäpalveluntarjoajille tai EDR-toimittajille. Ulkoistaminen voi parantaa kyvykkyyttä, mutta se ei ulkoista vastuuta.

NIS2 Article 21 sisältää toimitusketjun turvallisuuden ja toimittajasuhteet. DORA menee finanssialan toimijoiden osalta pidemmälle edellyttämällä ICT-kolmansien osapuolten riskistrategiaa, sopimusjärjestelyjen rekistereitä, huolellisuutta, keskittymäriskin analyysiä, auditointi- ja tarkastusoikeuksia, irtisanomisoikeuksia, poikkeama-apua, exit-strategioita ja vastuiden selkeää jakoa. ISO/IEC 27001:2022 liite A sisältää toimittajasuhteiden hallintakeinot, toimittajasopimukset, ICT-toimitusketjun kontrollit, toimittajapalvelujen seurannan ja muutoksenhallinnan sekä pilvipalvelujen hankinnan, käytön, hallinnan ja exitin.

Päätelaitesuojaamisen ulkoistuksen näytön tulisi sisältää:

• Toimittajahuolellisuusarviointi ennen käyttöönottoa.
• Sopimuslausekkeet seurannasta, poikkeamailmoituksista, pääsystä, tietojen sijainnista, auditointioikeuksista, palvelutasoista ja yhteistyöstä.
• Vastuutaulukko hälytysten triagelle, eristykselle, juurisyyanalyysille, raportoinnille ja näytön säilyttämiselle.
• Raportit, jotka osoittavat toimittajan suoriutumisen ja palvelutasosopimusten noudattamisen.
• Näyttö siitä, että toimittajapoikkeamat ja alustakatkokset katselmoidaan.
• Exit-suunnitelma, jos EDR- tai MDR-palveluntarjoaja epäonnistuu, sopimus päätetään tai palveluntarjoajasta tulee hyväksymätön.
• Vahvistus siitä, että lokit ja forensinen todistusaineisto pysyvät organisaation saatavilla.

Yleinen auditointivirhe on MDR-hallintanäkymä ilman omistajuutta. Organisaatio näkee hälytykset, mutta ei voi osoittaa, kuka omistaa riskin, mitä palveluntarjoajan on tehtävä, miten hälytysten laatua katselmoidaan tai miten näyttö säilytetään sääntely- ja oikeudellisia tarkoituksia varten.

Mittarit, jotka muuttavat päätelaitetyökalut johdon näytöksi

Hallitukset ja viranomaiset eivät tarvitse raakaa hälytysmäärää. Ne tarvitsevat indikaattoreita, jotka osoittavat, onko päätelaitteiden haittaohjelmariski hallinnassa.

Nämä mittarit tukevat ISO/IEC 27001:2022:n suorituskyvyn arviointia ja johdon katselmointia, NIS2:n hallintoelimen valvontaa, DORA:n hallinnointia ja ICT-riskistrategiaa, GDPR:n osoitusvelvollisuutta sekä sisäisen tarkastuksen suunnittelua.

Yritystason Päätelaitesuojaus- / haittaohjelmapolitiikan Soveltaminen ja vaatimustenmukaisuus -osiossa lauseke 8.2 toteaa:

Sisäisen tarkastuksen on tehtävä säännöllisiä katselmointeja päätelaitesuojausta koskevasta vaatimustenmukaisuudesta, mukaan lukien:

Sisäinen tarkastus voi muuttaa edellä olevat mittarit neljännesvuosittaiseksi kontrollitestiksi: ota otos päätelaitteista, vertaa inventaariota EDR-rekisteröinteihin, varmista reaaliaikainen tarkistus, katselmoi paikkaustila, vahvista, etteivät käyttäjät voi poistaa suojausta käytöstä, tarkasta viimeaikaiset haittaohjelmahälytykset ja jäljitä valitut hälytykset havainnosta sulkemiseen.

Yleiset päätelaitenäytön puutteet, joita Clarysec havaitsee

Jopa kypsät organisaatiot kamppailevat päätelaitenäytön laadun kanssa. Samat puutteet toistuvat usein:

• Omaisuusluettelo ja EDR-inventaario eivät täsmää.
• Kehittäjien työasemia hallitaan heikommin kuin tavanomaisia kannettavia.
• Mobiililaitteet jätetään päätelaitenäytön ulkopuolelle.
• BYOD-käyttö sallitaan ilman toteutettavissa olevia laitteen tietoturvan tilaa koskevia kontrolleja.
• EDR-agentit on asennettu, mutta peukaloinnin esto on poistettu käytöstä.
• Palveluntarjoaja seuraa hälytyksiä, mutta eskalointisäännöt ovat epäselvät.
• Karanteeniin asetettua haittaohjelmaa ei linkitetä poikkeamatikettiin.
• Juurisyyanalyysi ohitetaan ”estetyissä” havainnoissa.
• Korjauspäivityspoikkeuksista puuttuu riskinomistajan hyväksyntä tai päättymispäivä.
• Lokeja säilytetään liian lyhyen ajan tietoturvaloukkauksen arvioinnin tukemiseksi.
• Varmuuskopioiden palautusta testataan yleisesti, mutta ei kiristyshaittaohjelmaskenaarioita vasten.
• Hallitusraportointi näyttää hälytysmääriä eikä riskien vähentämistä.

Ratkaisu ei ole lisää laskentataulukoita. Ratkaisu on kytketty toimintamalli, jossa politiikka, inventaario, päätelaitteiden konfiguraatio, seuranta, tietoturvapoikkeamiin reagointi, toimittajahallinta, sääntelytriage, mittarit ja auditointitestaus vahvistavat toisiaan.

Kymmenen työpäivää päätelaitteiden haittaohjelmien torjunnan saattamiseksi auditointivalmiiksi

Jos tarvitset nopean aloituspisteen, tee seuraavat toimet seuraavan kymmenen työpäivän aikana:

1. Vie päätelaiteinventaario ja EDR-inventaario ja täsmäytä ne.
2. Tunnista hallitsemattomat, passiiviset, vanhentuneet, päällekkäiset ja poikkeukselliset päätelaitteet.
3. Vahvista reaaliaikainen tarkistus, peukaloinnin esto, automaattinen päivitys, eristys ja karanteeniasetukset.
4. Ota otos viidestä haittaohjelmahälytyksestä ja jäljitä kukin tutkintaan ja sulkemiseen.
5. Tarkista, voivatko päätelaitetapahtumat tukea NIS2-, DORA- ja GDPR-poikkeamatriagea.
6. Katselmoi MDR-, MSP- ja EDR-toimittajasopimukset poikkeamatuen, näyttöön pääsyn, auditointioikeuksien, palvelutasosopimusten ja exit-ehtojen osalta.
7. Lisää päätelaitteiden kattavuus, agenttien toimintakunto, eristysaika, paikkausvaatimustenmukaisuus ja juurisyyanalyysin valmistuminen johdon raportointiin.
8. Suorita sisäisen tarkastuksen otos käyttämällä Zenith Blueprint Step 19 -tarkistuslistaa.
9. Käytä Zenith Controls -opasta A.8.1:n ja A.8.7:n kartoittamiseen lokitukseen, seurantaan, haavoittuvuuksien hallintaan, tietoturvapoikkeamiin reagointiin, toimittajakontrolleihin ja palautumiseen.
10. Päivitä hallinnoinnin perustaso Clarysecin Päätelaitesuojaus- / haittaohjelmapolitiikan tai pk-yrityksille tarkoitetun Päätelaitesuojaus - haittaohjelmapolitiikan avulla.

Päätelaitteiden haittaohjelmien torjunnassa vuonna 2026 ei ole kyse vain kiristyshaittaohjelmien pysäyttämisestä. Kyse on sen osoittamisesta, että organisaatio pystyy ehkäisemään, havaitsemaan, rajaamaan, palautumaan, raportoimaan ja parantamaan.

Clarysec voi auttaa muuttamaan päätelaitesuojaamisen työkalun käyttöönotosta puolustettavaksi vaatimustenmukaisuuden poikittaiseksi näyttöjärjestelmäksi. Lataa Päätelaitesuojaus- / haittaohjelmapolitiikka, aloita pk-yrityksille tarkoitetulla Päätelaitesuojaus - haittaohjelmapolitiikalla, jos tarvitset kevyemmän toimintamallin, käytä Zenith Blueprint -opasta kontrollien toteuttamiseen ja käytä Zenith Controls -opasta päätelaitenäytön yhdistämiseen ISO/IEC 27001:2022:een, NIS2:een, DORA:an, GDPR Article 32:een, NIST CSF 2.0:aan ja auditointiodotuksiin.