Selainlaajennusten hallinta NIS2:n, DORA:n ja GDPR:n näkökulmasta

Maria, nopeasti kasvavan fintech-yhtiön tietoturvajohtaja, arvioi DORA-ennakkoarvioinnin etenevän hyvin. Hänen tiiminsä oli valmistellut ICT-kolmansien osapuolten rekisterin, kriittiset SaaS-sopimukset, toimittajien huolellisuusarviointien tallenteet, riskien hyväksymispäätökset ja hallintoelimen raportointipaketin.

Sitten auditoija esitti kysymyksen, johon kukaan ei ollut varautunut.

“Voitteko näyttää selainlaajennusten hallintaprosessinne?”

Kysymys nousi esiin päätelaitteen katselmoinnissa talousanalyytikon kanssa. Näytönjaon aikana auditoija huomasi analyytikon selaimessa kolmannen osapuolen tuottavuuslaajennuksen. Se vaikutti harmittomalta, mutta nopea haku osoitti, että kehittäjä oli joutunut toimitusketjun vaarantumisen kohteeksi kolme kuukautta aiemmin. Vaarantunutta laajennusta oli käytetty merkittävien SaaS-alustojen istuntotunnisteiden kaappaamiseen.

Fintech-yhtiöllä oli vahvat politiikat luvattomia ohjelmistoja vastaan. Sillä oli EDR, MFA, CASB, SaaS-lokit ja ISO/IEC 27001 -standardin mukainen tietoturvan hallintajärjestelmä. Kukaan ei kuitenkaan ollut käsitellyt selainta hallittuna ohjelmistoalustana. Kukaan ei ollut inventoinut laajennuksia. Kukaan ei ollut hyväksynyt niiden käyttöoikeuksia. Kukaan ei ollut tarkistanut, olivatko laajennusten kehittäjät toimittajia. Kukaan ei ollut kartoittanut laajennusten toimintaa DORA-, NIS2- tai GDPR-näyttöön.

Yksi selainlaajennus oli muuttanut vaatimustenmukaiselta näyttäneen päätelaitteen mahdolliseksi takaoveksi finanssijärjestelmiin, asiakastietoihin ja sääntelyn alaisiin työnkulkuihin.

Tämä on selainlaajennusten hallinnan ongelma vuonna 2026. Selain ei ole enää pelkkä ikkuna internetiin. Siellä työntekijät todentautuvat, hyväksyvät maksuja, käyttävät CRM-tietueita, käsittelevät henkilötietoja, hallinnoivat pilvi-infrastruktuuria ja työskentelevät kriittisten SaaS-alustojen kanssa. Laajennukset eivät ole enää kosmeettisia lisäosia. Ne ovat kolmannen osapuolen koodia, joka toimii modernin työn herkimmässä kerroksessa.

Tietoturvajohtajille, vaatimustenmukaisuuspäälliköille, tietosuojavastaaville ja ICT-riskien omistajille hallitsemattomat laajennukset sijoittuvat päätelaiteturvallisuuden, varjo-IT:n, toimittajariskin, muutoksenhallinnan, haavoittuvuuksien hallinnan ja tietosuojan osoitusvelvollisuuden leikkauspisteeseen. ISO/IEC 27001:2022 antaa organisaatioille rakenteen tämän riskin hallintaan. NIS2, DORA ja GDPR luovat sääntelypaineen sen osoittamiseen.

Selainlaajennukset ovat ohjelmistoja, toimittajia ja henkilötietojen käsittelijöihin liittyviä riskejä

Useimmat organisaatiot ovat jo oppineet hallitsemaan kannettavia tietokoneita, mobiililaitteita, palvelimia, SaaS-sovelluksia, pilvi-infrastruktuuria ja etuoikeutettuja tilejä. Selainlaajennukset jäävät usein näiden ohjelmien väliin.

Tietoturvatiimit näkevät ne selainasetuksina. Hankinta ei näe niitä, koska sopimusta ei allekirjoiteta. Lakiasiat eivät näe niitä, koska toimittajan käyttöönottopyyntöä ei avata. Tietosuojatiimit eivät näe niitä, koska käyttäjä asentaa laajennuksen eikä sitä oteta käyttöön virallisena sovelluksena. Laajennus voi silti pyytää oikeutta lukea ja muuttaa kaikkien verkkosivustojen tietoja, käyttää leikepöydän sisältöä, kerätä sivujen metatietoja, hallita latauksia, injektoida skriptejä tai viestiä ulkoisen taustajärjestelmän kanssa.

Tämä tarkoittaa, että selainlaajennus voi olla samanaikaisesti kaikkea seuraavaa:

[ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap tiivistää ydinkysymyksen ISO/IEC 27002:2022 -ohjeistuksessaan Control 8.19 -hallintakeinolle. Se varoittaa, että “hyvää tarkoittava henkilöstökin voi asentaa työkaluja ‘saadakseen työn tehtyä nopeammin’ – selainlaajennuksen, koodikirjaston tai tiedostonsiirtosovelluksen – ymmärtämättä, että se on juuri tuonut ympäristöön takaoven, paikkaamattoman riippuvuuden tai tietojen luvattoman siirron vektorin.”

Tätä lausetta tulee käsitellä hallitustason riskilausumana. Riskialttiita laajennuksia asentavat työntekijät eivät yleensä pyri kiertämään tietoturvaa. He pyrkivät parantamaan tuottavuutta. Hallintapuutteesta on kyse silloin, kun organisaatio ei tarjoa turvallista pyyntö-, hyväksyntä-, käyttöönotto- ja seurantaprosessia.

Miksi NIS2, DORA ja GDPR tekevät katvealueesta kiireellisen

Selainlaajennusriski on ollut olemassa vuosia, mutta sääntely-ympäristö on muuttunut. Vuonna 2026 organisaatioiden odotetaan osoittavan paitsi hallintakeinojen olemassaolo myös se, että ne ovat riskiperusteisia, integroituja, seurattuja ja näytöllä todennettavissa.

NIS2 nostaa odotuksia kyberhygieniasta ja toimitusketjun turvallisuudesta. DORA edellyttää finanssialan toimijoilta ICT-riskien hallintaa sisäisissä ja kolmansien osapuolten riippuvuuksissa. GDPR edellyttää rekisterinpitäjiltä ja henkilötietojen käsittelijöiltä käsittelyn turvallisuuden, osoitusvelvollisuuden ja sisäänrakennetun tietosuojan osoittamista. Hallitsemattomat laajennukset voivat heikentää kaikkia kolmea.

Johtopäätös on yksinkertainen. Selainlaajennus ei ole liian pieni ollakseen merkityksellinen. Jos se voi koskea sääntelyn alaisia tietoja, todennettuja istuntoja, talouden työnkulkuja tai kriittisiä SaaS-palveluja, sitä on hallittava.

Käytä ISO/IEC 27001:2022 -standardia toimintamallina

ISO/IEC 27001:2022 soveltuu hyvin selainlaajennusten hallintaan, koska se ei edellytä erillistä vaatimustenmukaisuussiiloa. Sen avulla organisaatiot voivat laajentaa nykyiset tietoturvan hallintajärjestelmän prosessit selainkerrokseen.

Käytännön kontrollimalli rakentuu kahdeksan ISO/IEC 27001:2022 Annex A -hallintakeinon ympärille:

[ZC] Zenith Controls: The Cross-Compliance Guide on erityisen hyödyllinen, koska se selittää, miten ISO/IEC 27001 -hallintakeinoja auditoidaan ja miten ne tukevat eri viitekehysten välistä näyttöä. Control 8.19 -hallintakeinon osalta Zenith Controls: The Cross-Compliance Guide selittää, että auditoijat “jäljittävät työnkulun: pyynnöstä testaukseen, hyväksyntään ja toteutukseen”. Juuri näin laajennusten hallinta tulee suunnitella.

Jos auditoija löytää laajennuksen, jota ei ole sallittujen luettelossa, jota ei ole dokumentoitu muutostallenteisiin eikä riskienarvioitu, kyse ei ole enää pelkästä selainasetuksesta. Siitä tulee näyttö heikosta ohjelmistojen asennuskontrollista, heikosta päätelaitteiden hallinnasta ja mahdollisesta toimittajariskin hallinnan epäonnistumisesta.

Vaihe 1: selvitä laajennuskanta

Marian fintech-yhtiön ensimmäinen kontrollipuutteita koskeva ongelma oli näkyvyys. Hänen tiiminsä ei tiennyt, mitä laajennuksia oli asennettu, kuka ne oli asentanut, mitä käyttöoikeuksia ne pyysivät tai muodostivatko ne yhteyksiä ulkoisiin palveluihin.

Kartoituksen tulee kattaa kaikki hallitut selaimet, profiilit, käyttäjät, laitteet ja käyttöjärjestelmät. Sen tulee tunnistaa laajennuksen nimi, yksilöllinen tunniste, versio, julkaisija, asennuslähde, käyttöoikeusjoukko, asennuspäivä, päivitystila, käyttäjämäärä, liiketoimintavastaava sekä se, onko laajennus asennettu pakotetusti, käyttäjän asentama, virallisen jakelukanavan ulkopuolelta asennettu vai estetty.

Control 8.1, Käyttäjien päätelaitteet, on ankkuri. Zenith Blueprint: An Auditor’s 30-Step Roadmap -ohjeistus Control 8.1 -hallintakeinolle toteaa, että käyttäjien päätelaitteet “on kovennettava, niitä on valvottava ja niitä on hallittava”. Tämä vaatimus sisältää luontevasti selaimen, koska selain on nykyisin ensisijainen käyttäjän päätelaiteliittymä SaaS- ja pilvityöhön.

Control 5.23 soveltuu myös silloin, kun laajennukset muodostavat yhteyden pilvipalveluihin. Zenith Blueprint: An Auditor’s 30-Step Roadmap kuvaa tämän hallintakeinon vastauksena varjo-IT:hen, jossa käyttäjät ottavat käyttöön hyväksymättömiä palveluja ilman hallintaa. Selainlaajennus, joka lähettää sisältöä tuntemattomaan isännöityyn taustajärjestelmään, on pilvipalvelun käyttöönottoa koskeva tapahtuma, vaikka kukaan hankinnassa ei olisi hyväksynyt sitä.

Kypsän kartoituksen tuotoksen tulee luokitella jokainen laajennus yhteen viidestä tilasta:

Kartoitus ei saa olla kertaluonteinen projekti. Laajennukset päivittyvät usein, julkaisijat vaihtavat omistajaa, käyttöoikeudet laajenevat ja sovelluskaupat poistavat haitallisia paketteja sen jälkeen, kun käyttäjät ovat jo asentaneet ne. Omaisuusluettelon on oltava jatkuva tai vähintään niin säännöllinen, että se tukee haavoittuvuuksien hallintaa ja auditointinäyttöä.

Vaihe 2: tee hyväksyttävä käyttö nimenomaiseksi

Kun laajennukset ovat näkyvissä, käyttäjiin kohdistuvien odotusten on oltava selkeitä. Monilla organisaatioilla on jo politiikkakieltä, joka tukee laajennusten hallintaa, mutta sitä on sovellettava selaimeen nimenomaisesti.

[P-EPM] Päätelaitesuojaus- ja haittaohjelmapolitiikka pk-yrityksille toteaa, että käyttäjät “eivät saa asentaa luvattomia ohjelmistoja tai lisäosia, jotka voivat aiheuttaa riskin”. Tämä yksittäinen lause antaa tietoturvatiimeille vahvan politiikkaperustan käsitellä selainlaajennuksia hallittuina ohjelmistoina.

[P03-AUP] P03 Hyväksyttävän käytön politiikka, johon viitataan myös yritystason hyväksyttävän käytön politiikkana, kieltää “hyväksymättömät työkalut: luvattomien ohjelmistojen, laitteistojen, pilvipalvelujen tai laitteiden asentamisen tai käytön”. Tämä on käyttäjille näkyvä perusta. Se muuttaa selainlaajennusten hallinnan teknisestä mieltymyksestä täytäntöönpantavaksi käyttäytymis- ja vaatimustenmukaisuusvaatimukseksi.

Vahvan selainlaajennuspolitiikan tulee vastata kuuteen käytännön kysymykseen:

Tarkoituksena ei ole kieltää kaikkia hyödyllisiä laajennuksia. Tarkoituksena on siirtyä implisiittisestä luottamuksesta nimenomaiseen hyväksyntään. Osa laajennuksista voi olla turvallisia, tarpeellisia ja tuottavuutta parantavia. Toiset voivat olla tarpeettomia, ylioikeutettuja, hylättyjä tai vihamielisiä. Hallintaohjelman on erotettava nämä toisistaan.

Vaihe 3: toteuta oletusarvoinen esto ja poikkeusperusteinen sallittujen luettelo

Control 8.19, Ohjelmistojen asentaminen tuotantojärjestelmiin, on hallintakeino, joka muuttaa politiikan operatiiviseksi toiminnaksi. Selainlaajennuksia ei tule kohdella eri tavalla kuin muita ohjelmistoja vain siksi, että käyttäjät asentavat niitä selaimen sovelluskaupasta.

Zenith Blueprint: An Auditor’s 30-Step Roadmap ilmaisee asian suoraan: “mitään ohjelmistoa ei asenneta, ellei se ole perusteltu, valtuutettu ja suojattu”. Selainlaajennusten osalta tämä tarkoittaa yritystason selaimenhallinnan, päätelaitteiden hallinnan tai laitekonfiguraatiotyökalujen käyttöä asennussääntöjen toteuttamiseksi.

Puolustettavin malli on oletusarvoinen esto ja poikkeusperusteinen sallittujen luettelo:

1. Estä kaikki laajennukset oletusarvoisesti hallituissa selaimissa.
2. Asenna pakotetusti vain välttämättömät ja hyväksytyt yrityslaajennukset.
3. Ylläpidä hyväksyttyjen laajennusten sallittujen luetteloa käyttäjäryhmän, osaston tai roolin mukaan.
4. Estä virallisen jakelukanavan ulkopuolelta asennetut laajennukset ja epäluotettavat asennuslähteet.
5. Estä käyttäjiä kiertämästä politiikkoja vaihtamalla profiileihin tai hallitsemattomiin selaimiin.
6. Poista jo asennetut laajennukset, joita ei ole hyväksytty.
7. Katselmoi laajennusten käyttöoikeudet ja julkaisijariski ennen hyväksyntää.
8. Kirjaa sallitut, estetyt, poistetut ja muutetut laajennukset lokiin.

Osa organisaatioista aloittaa pehmeämmällä mallilla operatiivisen monimutkaisuuden vuoksi. Ne voivat ensin inventoida, estää tunnetusti haitalliset laajennukset ja ottaa sen jälkeen sallittujen luettelot vaiheittain käyttöön korkean riskin ryhmille, kuten taloushallinnolle, suunnittelulle, etuoikeutetuille ylläpitäjille, lakiasioille, henkilöstöhallinnolle ja asiakastuelle. Tämä on hyväksyttävää, jos etenemissuunnitelma on dokumentoitu. Puolustettavaa ei ole tuntemattoman laajennusriskin pysyvä sietäminen.

Vaihe 4: riskienarvioi laajennukset kuten toimittajat ja ohjelmistot

Selainlaajennuksen riskikatselmoinnin tulee olla riittävän kevyt liiketoiminnan käyttöön, mutta riittävän vahva kestämään auditointi. Katselmoinnin tulee yhdistää ohjelmistoriski, toimittajariski, pilviriski, tietosuoja ja haavoittuvuuksien hallinta.

[P-TP] Kolmansien osapuolten ja toimittajien tietoturvapolitiikka edellyttää, että “kaikille uusille toimittajille tehdään dokumentoitu tietoturva-arviointi ennen sopimuksen täytäntöönpanoa”. Kaikki laajennuskehittäjät eivät edellytä täyttä yritystason toimittajan käyttöönottoprosessia, mutta toimittajariskin periaate soveltuu silti. Jos kehittäjä voi työntää koodipäivityksiä työntekijöiden selaimiin tai käsitellä organisaation tietoja taustajärjestelmän kautta, organisaatiolla on kolmannen osapuolen riippuvuus.

[P-ASR] Sovellusturvallisuusvaatimusten politiikka pk-yrityksille vahvistaa saman vaatimuksen ohjelmistonäkökulmasta: “kaikki sovelluksessa käytettävät kolmannen osapuolen työkalut, lisäosat tai ulkoiset koodikirjastot on kirjattava ja katselmoitava vuosittain tietoturvavaikutuksen ja paikkaustilan osalta”.

Käytä seuraavaa riskimallia päätösten yhdenmukaistamiseen:

Korkean riskin laajennusta ei tule hyväksyä, ellei ole kriittistä liiketoimintatarvetta, dokumentoituja kompensoivia hallintakeinoja ja ylemmän johdon riskin hyväksyntää. Esimerkkejä kompensoivista hallintakeinoista ovat käytön rajoittaminen kovennettuun selainprofiiliin, käytön rajaaminen tiettyihin URL-osoitteisiin, tietojen syötön estäminen arkaluonteisiin sovelluksiin laajennuksen ollessa aktiivinen, DLP-seurannan käyttö tai toimittajasopimuksen ja tietosuojaliitteen edellyttäminen.

Vaihe 5: integroi tietosuoja- ja GDPR-katselmointi

Selainlaajennusten hallinta epäonnistuu usein, koska tietosuojakatselmointi on irrotettu päätelaitetyökaluista. Monet laajennukset voivat kuitenkin nähdä SaaS-sovelluksissa, henkilöstöhallinnon järjestelmissä, tukipyynnöissä, CRM-tietueissa, sähköpostissa, analytiikka-alustoilla ja yhteistyövälineissä näkyviä henkilötietoja.

GDPR Article 5(2) -kohdan mukaan organisaation on osoitettava osoitusvelvollisuus. Article 25 -kohdan mukaan sen on toteutettava sisäänrakennettu ja oletusarvoinen tietosuoja. Article 32 -kohdan mukaan sen on sovellettava asianmukaisia teknisiä ja organisatorisia toimenpiteitä käsittelyn turvallisuuteen. Jos laajennus siirtää henkilötietoja luvattomasti, tapahtumasta voi tulla Article 4(12) -kohdan mukainen henkilötietojen tietoturvaloukkaus, joka käynnistää arvioinnin ja mahdollisesti Article 33 -ilmoitusvelvoitteet.

Tietosuojatietoisen laajennuskatselmoinnin tulee kysyä:

Kaikki laajennukset eivät edellytä täyttä DPIA-arviointia. Laajennukset, joilla on laaja pääsy sivujen sisältöön, AI-käsittelyä, näytönkaappausta, sähköpostipääsy, CRM-pääsy, HR-tietojen käyttöä, asiakastuen tietoja tai sääntelyn alaisia taloustietoja, tulisi kuitenkin ohjata rakenteelliseen tietosuojan arviointiin.

Vaihe 6: lokita ja seuraa auditointia ja tietoturvapoikkeamiin reagointia varten

Laajennusten hallintaohjelma ilman lokeja ei ole auditoitavissa. Se myös heikentää tietoturvapoikkeamiin reagointia, koska organisaatio ei voi määrittää, milloin laajennus asennettiin, kuka sitä käytti, mikä versio oli käytössä, milloin käyttöoikeudet muuttuivat tai tapahtuiko estetty asennusyritys.

[P-LM] Lokitus- ja valvontapolitiikka pk-yrityksille määrittää “ohjelmistoasennusten” lokit keskeiseksi hallintavaatimukseksi. Selainlaajennuksen asennus on ohjelmistoasennustapahtuma, ja se tulee tallentaa vastaavasti.

Vähintään lokien tulee sisältää:

Näiden lokien tulee syöttää seurantaprosesseja Controls 8.15 ja 8.16 -hallintakeinojen mukaisesti. Riskistä riippuen ne voivat myös siirtyä SIEM-järjestelmään, päätelaitealustalle tai vaatimustenmukaisuuden näyttötietovarastoon. Hälytykset tulee määrittää estetyille korkean riskin laajennuksille, laajennuspyyntöjen äkillisille piikeille, hyväksyttyjen laajennusten käyttöoikeusmuutoksille, epävirallisista lähteistä tehtäville asennusyrityksille ja etuoikeutettujen käyttäjien asennusyrityksille.

Seuranta on etu myös NIS2:n ja DORA:n näkökulmasta. NIS2 Article 23 -poikkeamaraportointi riippuu varhaisesta havaitsemisesta ja vaikutusten arvioinnista. DORA edellyttää vahvaa ICT-poikkeamien käsittelyä ja häiriönsietokyvyn näyttöä. GDPR-loukkausarviointi riippuu tiedosta, mitä tapahtui, milloin ja mihin tietoihin vaikutus mahdollisesti kohdistui.

Mitä auditoija haluaa nähdä

Auditoijalle riittää harvoin toteamus, kuten “estämme riskialttiit laajennukset”. Hän haluaa näyttöä hallinnasta. Näytön on yhdistettävä politiikka, riskienarviointi, tekninen toimeenpano, seuranta ja johdon vastuuvelvollisuus.

Tässä Zenith Controls: The Cross-Compliance Guide muuttuu arvokkaaksi. Se auttaa organisaatioita osoittamaan, miten yksi kontrollitoiminto tukee useita vaatimustenmukaisuusodotuksia. Yksi selainlaajennuksen hyväksyntätyönkulku voi tukea ISO/IEC 27001 Control 8.19 -hallintakeinoa, NIS2:n kyberhygieniaa, DORA:n ICT-riskien hallintaa ja GDPR:n osoitusvelvollisuutta, jos näyttö säilytetään ja kartoitetaan selkeästi.

Vastaavuustaulukko: ISO/IEC 27001:2022 suhteessa NIS2:een, DORA:an ja GDPR:ään

Käytännön vastaavuustaulukko auttaa tietoturvajohtajia selittämään, miksi selainlaajennusten hallinta ei ole kapea tekninen kontrolli. Se on vaatimustenmukaisuuskontrolli, jolla on laaja sääntelyarvo.

DORA-kartoitus ansaitsee erityistä huomiota. Osa auditoijista ja arvioijista käyttää COBIT-tyyppistä kieltä katselmoidessaan ICT-muutosten hallintaa. COBIT BAI06 ymmärretään yleisesti Managed IT Changes -alueeksi. Jos selainlaajennukset ovat ohjelmistoja ja niiden asennus muuttaa käyttäjän tietoteknistä ympäristöä, laajennusten asennus kuuluu samaan hallittuun muutoslogiikkaan. Zenith Controls: The Cross-Compliance Guide tukee tätä auditointinäkökulmaa osoittamalla, miten ISO/IEC 27001 -hallintakeinojen näyttöä voidaan käyttää uudelleen eri vaatimustenmukaisuusodotuksissa.

90 päivän toteutussuunnitelma selainlaajennusten hallintaan

Organisaatioiden ei tarvitse ratkaista kaikkea yhdessä viikossa. Käytännön ohjelma voidaan rakentaa vaiheittain, erityisesti jos liiketoimintahäiriöitä on hallittava huolellisesti.

Korkean riskin organisaatioissa, erityisesti DORA:n alaisissa finanssialan toimijoissa tai NIS2:n mukaisissa keskeisissä ja tärkeissä toimijoissa, ensimmäisen soveltamisvaiheen tulee priorisoida käyttäjät, joilla on pääsy kriittisiin järjestelmiin, sääntelyn alaisiin tietoihin, etuoikeutettuihin hallintakonsoleihin, talousalustoihin, asiakastukityökaluihin ja kehittäjäympäristöihin.

Hallitustason viesti

Selainlaajennusten hallintaa ei tule esittää ylimmälle johdolle selaimen koventamisprojektina. Se tulee esittää kontrollina, joka koskee arvioimatonta kolmannen osapuolen koodia sääntelyn alaisissa työnkuluissa.

Hallituksen ja hallintoelimen on ymmärrettävä neljä asiaa:

1. Selain on nykyisin keskeinen liiketoiminta-alusta.
2. Laajennukset voivat käyttää arkaluonteista SaaS-dataa ja todennettuja istuntoja.
3. Hallitsemattomat laajennukset aiheuttavat toimittaja-, tietosuoja-, poikkeama- ja häiriönsietokykyriskejä.
4. ISO/IEC 27001:2022 tarjoaa puolustettavan kontrollimallin, joka tukee NIS2-, DORA- ja GDPR-näyttöä.

Tämä kehystys siirtää keskustelun teknisestä mieltymyksestä toiminnan häiriönsietokykyyn. Se tukee myös rahoitusta yritystason selaimenhallinnalle, päätelaitteiden integraatiolle, seurannalle, tietosuojakatselmoinnille, toimittajan alkuarvioinnille ja auditointinäytön automatisoinnille.

Katvealueesta strategiseksi kontrolliksi

Marian auditointiongelma ei johtunut siitä, että yksi analyytikko asensi yhden tuottavuustyökalun. Se johtui hallitsemattomasta riskiluokasta. Organisaatio oli rakentanut vahvan vaatimustenmukaisuusohjelman näkyvien omaisuuserien, näkyvien toimittajien, näkyvien SaaS-alustojen ja näkyvien päätelaitteiden ympärille, mutta selainlaajennuskerros jäi näkymättömäksi.

Tätä aukkoa ei voi enää sivuuttaa.

Korjaus ei ole monimutkainen, mutta sen on oltava harkittu. Käsittele selainta osana päätelaitetta. Käsittele laajennuksia ohjelmistoina. Käsittele laajennusten kehittäjiä ja taustajärjestelmiä toimittajina silloin, kun se on relevanttia. Käsittele käyttöoikeuksia tietojen käyttönä. Käsittele asennusta muutoksena. Käsittele lokeja vaatimustenmukaisuuden näyttönä.

Puolustettava ohjelma alkaa neljällä toimella:

1. Selvitä kaikki laajennukset hallituissa selaimissa ja päätelaitteissa.
2. Määritä hyväksyttävän käytön ja oletusarvoisen eston säännöt käyttämällä Päätelaitesuojaus- ja haittaohjelmapolitiikka pk-yrityksille-, P03 Hyväksyttävän käytön politiikka- ja yritystason hyväksyttävän käytön politiikka -asiakirjoja.
3. Arvioi laajennuspyynnöt toimittaja-, pilvi-, haavoittuvuus- ja tietosuojakriteereillä, jotka perustuvat Kolmansien osapuolten ja toimittajien tietoturvapolitiikka- ja Sovellusturvallisuusvaatimusten politiikka pk-yrityksille -asiakirjoihin.
4. Toteuta ja seuraa asennustoimintaa selaimenhallinnan, lokituksen ja näyttökäytäntöjen avulla Lokitus- ja valvontapolitiikka pk-yrityksille -asiakirjan mukaisesti.

NIS2-, DORA-, GDPR- tai ISO/IEC 27001:2022 -auditointeihin valmistautuville tietoturvajohtajille selainlaajennusten hallinta on korkean arvon kontrolliparannus, koska se sulkee todellisen hyökkäyspolun ja tuottaa uudelleenkäytettävää näyttöä eri viitekehyksissä.

Työn nopeuttamiseksi lataa Zenith Blueprint: An Auditor’s 30-Step Roadmap ja kartoita näyttösi Zenith Controls: The Cross-Compliance Guide -oppaan avulla. Jos haluat muuttaa selainlaajennuskaaoksen auditointivalmiiksi hallintaohjelmaksi, varaa Clarysec-arviointi tai demo ja aloita käytännön inventaariolla, riskikartalla ja 90 päivän kontrollisuunnitelmalla.