Hallitse MFA-väsymystä ja push bombing -hyökkäyksiä

Kello 2.13 tullut push-ilmoitus, josta tuli hallituksen kysymys

Kello 2.13 taloushallinnon vanhempi järjestelmänvalvoja saa mobiili-ilmoituksen: ”Hyväksytäänkö kirjautuminen?” Hän on puoliksi unessa, olettaa kyseessä olevan pilvipohjaisen taloushallintoalustan aikakatkaisu ja napauttaa hyväksyntää.

Kello 2.19 hyökkääjä on identiteetintarjoajan sisällä. Kello 2.31 hän yrittää päästä palkka-aineiston vientiin, etuoikeutettuun pilvikonsoliin ja toimittajamaksuissa käytettyyn jaettuun postilaatikkoon. Kello 3.05 SOC havaitsee toistuvia MFA-kehotteita, epätavallisen maantieteellisen sijainnin, onnistuneen hyväksynnän ja uuden istunnon hallitsemattomalta laitteelta.

Aamun keskustelu on tuttu:

• ”Mutta meillähän oli MFA käytössä.”
• ”Miksi käyttäjä hyväksyi sen?”
• ”Kirjasimmeko MFA-haasteen yksityiskohdat lokiin?”
• ”Onko tämä henkilötietojen tietoturvaloukkaus?”
• ”Onko meillä 24 tai 72 tunnin raportointivelvoitteita?”
• ”Käsitteleekö ISO 27001:2022 -auditoijamme tämän kontrollin epäonnistumisena?”
• ”Vaikuttaako tämä NIS2:een, DORA:an, GDPR:ään, asiakassopimuksiin tai kybervakuutukseen?”

Tämä on MFA-väsymyksen ja push bombing -hyökkäysten taustalla oleva hallinnon aukko. Hyökkääjät eivät murra kryptografiaa. He uuvuttavat ihmisen päätöksentekoa, hyödyntävät heikkoa todennussuunnittelua ja etsivät valvomattomia poikkeuksia. Kontrollin epäonnistuminen on harvoin ”MFA ei ollut käytössä”. Yleensä kyse on ketjusta, johon kuuluvat heikko identiteetin varmentaminen, riskialtis push-hyväksynnän toteutus, puuttuva numerovastaavuus, epäselvät etuoikeutetun pääsyn säännöt, riittämätön todennuslokitus, heikko hälytysten luokittelu ja priorisointi, puutteellisesti koulutetut käyttäjät sekä dokumentoidun näytön puuttuminen siitä, että organisaatio on arvioinut ja korjannut heikkouden.

Tietoturvajohtajien, vaatimustenmukaisuuspäälliköiden, auditoijien ja liiketoimintavastuullisten on käsiteltävä MFA-väsymystä ISMS:n todentavan aineiston ongelmana, ei vain identiteetintarjoajan asetuksena. Ratkaisu yhdistää ISO 27001:2022 -riskien käsittelyn, ISO/IEC 27002:2022 -kontrollit, politiikkavelvoitteet, käyttäjien tietoisuuden, tietoturvapoikkeamiin reagoinnin, toimittajahallinnan sekä NIS2-, DORA-, GDPR-, NIST CSF 2.0- ja COBIT 2019 -viitekehysten väliset vastaavuudet.

MFA-väsymys on todennuksen epäonnistuminen, ei käyttäjäongelma

MFA-väsymys, jota kutsutaan myös push bombingiksi tai MFA-kehotteiden pommittamiseksi, syntyy, kun kelvollisen salasanan saanut hyökkääjä käynnistää toistuvasti MFA-hyväksyntäpyyntöjä, kunnes käyttäjä hyväksyy yhden. Joskus hyökkääjä lisää sosiaalista manipulointia, kuten väärennetyn helpdesk-puhelun, viestin ”testaamme käyttäjätiliäsi” tai pyynnön hyväksyä kirjautuminen ilmoitusten lopettamiseksi.

Operatiivinen riski on siinä, että organisaatiot käsittelevät usein kaikkia MFA-menetelmiä samanarvoisina. Ne eivät ole sitä.

Yksinkertainen ”hyväksy tai hylkää” -push-ilmoitus on heikompi kuin numerovastaavuus, tietojenkalastelua kestävät FIDO2-turva-avaimet, varmennepohjainen todennus tai ehdollinen käyttö, joka estää mahdottoman matkustuksen ja hallitsemattomat laitteet. MFA epäonnistuu myös silloin, kun ohituspoikkeuksia ei ole dokumentoitu, palvelutilit ovat interaktiivisia, vanhentuneet todennusprotokollat ovat edelleen käytössä tai korkean riskin pääsy ei edellytä vahvempaa todennusta.

Zenith Blueprint: auditoijan 30 vaiheen tiekartta -oppaassa Clarysec sijoittaa turvallisen todennuksen Controls in Action -vaiheeseen, vaiheeseen 19: teknologiset kontrollit I. Ohje on suora:

Todennus on ensimmäinen ja kriittisin puolustuslinja uhkatoimijan ja järjestelmiesi, tietojesi ja palvelujesi välillä. Jos todennus on heikko, kaikki muu – salaus, seuranta ja segmentointi – voidaan ohittaa.

Sama Zenith Blueprint käsittelee myös ISO/IEC 27002:2022 -kontrollia 5.17 vaiheessa 22:

Jos identiteetti vastaa kysymykseen ”kuka olet?”, todennus on näyttö. Kontrolli 5.17 on kohta, jossa teoria muuttuu luottamukseksi. Se edellyttää, että todennustietoja hallitaan turvallisesti koko niiden elinkaaren ajan, jotta identiteetin varmentamiseen käytetyt menetelmät ja tunnistetiedot eivät itse muutu heikoimmaksi lenkiksi.

Nämä kaksi lausetta selittävät, miksi push bombing kuuluu riskirekisteriin. Salaus ei auta, jos hyökkääjästä tulee hyväksytty käyttäjä. Verkon segmentointi auttaa vähemmän, jos etuoikeutettu pilvipääsy hyväksytään väsyneen käyttäjän kehotteella. Seuranta toimii vain, jos todennustapahtumat kirjataan lokiin riittävän yksityiskohtaisesti ja katselmoidaan nopeasti.

Kypsän riskilausuman on oltava täsmällinen:

Tässä ISO 27001:2022 on olennainen. Standardi edellyttää toimintaympäristön ja sidosryhmien määrittelyä, johtajuutta, riskien arviointia, käsittelysuunnittelua, operatiivista ohjausta, seurantaa, sisäistä auditointia, johdon katselmointia ja jatkuvaa parantamista. MFA-väsymys koskettaa niitä kaikkia.

ISO 27001:2022 -kontrollikokonaisuus, jota auditoijat testaavat

ISO 27001:2022 antaa hallintajärjestelmän rakenteen. ISO/IEC 27002:2022 antaa kontrollien toteutusohjeistuksen. MFA-väsymyksen ja push bombing -hyökkäysten osalta auditoijat keskittyvät yleensä kontrollikokonaisuuteen yhden yksittäisen kontrollin sijaan.

Clarysecin Zenith Controls: eri vaatimusten välinen opas kartoittaa ISO/IEC 27002:2022 -kontrollin 8.5 Turvallinen todennus tukikontrolleihin, kuten 5.17 Todennustiedot, 8.2 Etuoikeutetut käyttöoikeudet, 8.16 Seurantatoiminnot, 5.24 Tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu sekä 5.34 Yksityisyys ja PII:n suojaaminen. Tämä ristiinkytkentä on tärkeä, koska kuvakaappaus tekstillä ”MFA käytössä” ei riitä. Auditoijat haluavat näytön siitä, että todennus on suunniteltu, sitä seurataan, se katselmoidaan ja sitä parannetaan riskin perusteella.

Puolustettavan näyttöpaketin tulisi sisältää:

1. Riskien arviointi, jossa tunnistetaan push bombing ja MFA-kehotteisiin kohdistuva sosiaalinen manipulointi.
2. Todennusstandardi, joka määrittää hyväksyttävät MFA-menetelmät järjestelmän kriittisyyden mukaan.
3. Etuoikeutetun pääsyn politiikka, joka edellyttää vahvempaa todennusta ylläpitäjä- ja etäkäytössä.
4. Identiteetintarjoajan konfiguraatiovienti, joka osoittaa numerovastaavuuden, kehoterajoitukset, ehdollisen käytön ja estetyn vanhentuneen todennuksen.
5. Lokit, jotka osoittavat onnistuneet ja epäonnistuneet MFA-tapahtumat, hylätyt kehotteet, mahdottoman matkustuksen ja laitekontekstin.
6. Hälytyssäännöt toistuville MFA-kehotteille, toistuville epäonnistumisille ja epätavalliselle onnistuneelle hyväksynnälle.
7. Tietoturvapoikkeamiin reagoinnin tallenteet todennukseen liittyvistä hälytyksistä.
8. Tietoisuuskoulutuksen sisältö, jossa käyttäjiä ohjeistetaan olemaan hyväksymättä odottamattomia kehotteita.
9. Etuoikeutettujen ja vaikutuksiltaan merkittävien järjestelmien käyttöoikeuskatselmointien tallenteet.
10. Poikkeusrekisteri, jossa on voimassaolon päättymispäivät, riskinomistajien hyväksynnät ja korvaavat kontrollit.

Politiikka muuttaa ohjeen ”älä hyväksy odottamattomia kehotteita” todentavaksi aineistoksi

Monet organisaatiot ohjeistavat käyttäjiä olemaan hyväksymättä epäilyttäviä kehotteita. Ohje on hyödyllinen, mutta se ei riitä ISO 27001:2022 -sertifiointiin, NIS2-valvontaan, DORA-häiriönsietokykyyn, GDPR:n osoitusvelvollisuuteen, asiakkaiden due diligence -arviointeihin tai kybervakuutukseen.

Ensimmäinen politiikka-ankkuri on P38 Secure Communications and Multi-Factor Authentication (MFA) Policy. Se käsittelee suoraan inhimillistä puolta:

Käyttäjien tietoisuus: Käyttäjille on annettava koulutus turvallisten ja turvattomien viestintäkanavien erottamiseen. Koulutuksen tulee kattaa monivaiheisen todennuksen (MFA) asianmukainen käyttö, esimerkiksi odottamattomien kirjautumiskehotteiden hyväksymättä jättäminen, sekä turvallisen viestinnän käytännöt, esimerkiksi videokokouslinkkien varmentaminen ja luottamuksellisten aiheiden käsittelemättä jättäminen suojaamattomilla yhteyksillä.

Tämä muuttaa MFA-väsymyksen koulutusvelvoitteeksi, ei syyllistämisharjoitukseksi. Sen avulla tietoturvajohtaja voi osoittaa, että MFA-kehotteiden pommittaminen katetaan perehdytyksessä, kertauskoulutuksessa, roolipohjaisessa koulutuksessa ja etuoikeutettujen käyttäjien tiedotuksissa.

Sama P38 Secure Communications and Multi-Factor Authentication (MFA) Policy luo myös seurantavelvoitteen:

Tietoturvatoiminto seuraa jatkuvasti todennuslokeja yksivaiheisen kirjautumisen yritysten tai poikkeavien monivaiheisen todennuksen (MFA) epäonnistumisten varalta. Suojattujen viestintäjärjestelmien lokit on soveltuvin osin seurattava luvattomien pääsyyritysten tai konfiguraatiomuutosten varalta.

Pk-yrityksille P11S User Account and Privilege Management Policy - SME asettaa käytännöllisen perustason:

Monivaiheinen todennus (MFA) on otettava käyttöön, jos se on teknisesti toteutettavissa, ylläpitäjätileille tai arkaluonteisille järjestelmille.

Ilmaus ”jos se on teknisesti toteutettavissa” ei saa koskaan muuttua porsaanreiäksi. Jos järjestelmä ei tue vahvaa MFA:ta, poikkeus on kirjattava omistajan, päättymispäivän, korvaavien kontrollien, seurannan ja migraatiosuunnitelman kanssa. Suuremmat organisaatiot voivat yhdenmukaistaa saman odotuksen P11 User Account and Privilege Management Policy -politiikkaan ja testata sen jälkeen, vastaavatko politiikka ja operatiivinen todellisuus toisiaan.

Havaitsemista koskeva näyttö tulee P22S Logging and Monitoring Policy - SME -politiikasta, joka edellyttää todennustapahtumien lokitusta:

Todennuslokit: onnistuneet ja epäonnistuneet kirjautumisyritykset, istunnon kesto, MFA-käyttö

Se edellyttää myös korkean riskin todennussignaalien kiireellistä katselmointia:

Välitön katselmointi korkean vakavuuden hälytysten havaitsemisen yhteydessä, esimerkiksi haittaohjelmat, epäonnistunut monivaiheinen todennus (MFA) ja toistuvat kirjautumisepäonnistumiset.

Tietoisuuden on kehityttävä uhkien mukana. Information Security Awareness and Training Policy - SME tukee tätä palautesilmukkaa:

Aiheiden on sisällettävä esiin nousevat uhat, esimerkiksi tietojenkalastelu, olennaiset politiikkamuutokset ja sisäiset poikkeamatrendit.

Kun SOC havaitsee MFA-väsymysyrityksiä, tiedon tulee ohjata käyttäjävaroituksia, helpdesk-skriptejä, pöytäharjoituksia ja koulutuspäivityksiä.

Hallittu MFA-väsymyksen kontrollipaketti

Oletetaan, että organisaatio käyttää pilvipohjaista identiteetintarjoajaa, SaaS-pohjaista CRM:ää, taloushallintoalustaa, VPN:ää ja hallinnoitua tietoturvapalveluntarjoajaa. Tavoitteena on hallita MFA-väsymystä Clarysecin Zenith Blueprint -oppaan, politiikkakirjaston ja Zenith Controls -vaatimustenmukaisuusoppaan avulla.

Aloita Zenith Blueprint -oppaan vaiheesta 19, jossa tiimejä ohjeistetaan määrittämään todennusvaatimukset järjestelmäkohtaisesti ja varoitetaan, että pelkkään salasanaan perustuvaa todennusta tulee välttää ylläpitäjätileillä, pilvikonsoleissa, etäkäyttötyökaluissa ja internetiin avautuvissa järjestelmissä. Sovella sen jälkeen käytännön katselmointitoimea:

Katselmoi MFA-käyttöönotto: tunnista mahdolliset puutteet ja suunnittele niiden korjaaminen. Varmista, että palvelutilit ovat mahdollisuuksien mukaan ei-interaktiivisia, niillä on vahvat tunnistetiedot ja ne on dokumentoitu. Varmista, ettei missään järjestelmässä tai sovelluksessa ole jäljellä oletustunnistetietoja.

Muunna ohjeistus operatiiviseksi kontrollipaketiksi.

Vaihe 1: luokittele järjestelmät todennusriskin mukaan

Vaihe 2: poista korkean riskin push-käyttäytyminen

Poista perustason push-hyväksyntä ylläpitäjä- ja vaikutuksiltaan merkittäviltä tileiltä. Käytä tietojenkalastelua kestäviä todentimia aina kun mahdollista. Jos push jää käyttöön, pakota numerovastaavuus, sovelluskonteksti, maantieteellinen konteksti, laitesidonta ja kehotteiden nopeusrajoitukset. Estä vanhentunut todennus ja edellytä uudelleentodennusta riskialttiissa istunnoissa.

Vaihe 3: määritä MFA-väsymyksen hälytyssäännöt

Käytännöllisen SIEM-säännön tulee laueta, kun yksi tai useampi seuraavista malleista tapahtuu lyhyessä aikaikkunassa:

• Kolme tai useampi MFA-push-kehote yhdelle käyttäjälle.
• Kaksi hylättyä kehotetta, joita seuraa yksi hyväksytty kehote.
• MFA-hyväksyntä uudesta maantieteellisestä sijainnista tai hallitsemattomalta laitteelta.
• MFA-kehote salasanaruiskutuksen tai tunnistetietojen massakokeilusignaalin jälkeen.
• MFA-hyväksyntä etuoikeutettuun pääsyyn normaalin työajan ulkopuolella.
• Uuden todentimen rekisteröinti pian epäonnistuneiden kirjautumisyritysten jälkeen.

Hälytyksen tulee luoda poikkeamatiketti, ilmoittaa SOC:lle tai tietoturvavastaavalle ja edellyttää rajaamistoimia: istunnon keskeyttäminen, refresh-tokenien peruuttaminen, salasanan palauttamisen vaatiminen, laitteen varmentaminen, käyttäjän haastattelu, istunnon aikaisen pääsyn katselmointi sekä sen luokittelu, koskiko tapahtuma henkilötietoja tai kriittisen palvelun vaikutusta.

Vaihe 4: kytke tietosuoja- ja poikkeamatallenteet

Jos käyttäjätilillä on pääsy henkilötietoihin, sovella PII Security and Access Control Policy -politiikkaa. Se edellyttää vahvaa todennusta ennen vaikutuksiltaan merkittävää PII-pääsyä:

[Both] Tietoturvavastaavan TULEE edellyttää vahvaa todennusta etuoikeutetulle, etäkäytölle, hallinnolliselle tai vaikutuksiltaan merkittävälle PII-pääsylle ennen tällaisen pääsyn käyttöönottoa ja kirjata vaatimus REG12:een.

Se edellyttää myös lokituksen soveltamisalan määrittämistä:

[Both] Järjestelmäomistajan / sovellusomistajan TULEE määrittää PII-lokituksen soveltamisala todennustapahtumille, käyttötapahtumille, etuoikeutetuille toimille, PII-vienneille ja olennaisille konfiguraatiomuutoksille REG12:ssa ennen tuotantokäyttöä tai olennaista muutosta.

Kun seuranta viittaa luvattomaan PII-pääsyyn, se luo velvoitteen poikkeamatallenteen avaamiseen:

[Conditional] Tietoturvapoikkeamiin reagoinnin koordinaattorin TULEE avata REG10-tallenne tai linkittää siihen yhden työpäivän kuluessa, kun seuranta viittaa epäiltyyn luvattomaan PII-pääsyyn, epäiltyyn PII-luovutukseen, epäiltyyn PII:n muuttamiseen tai epäiltyyn PII:n saatavuuden menetykseen.

Tietosuojan eskaloinnin täydentää PII Incident and Breach Management Policy:

[Conditional] Tietosuojavastaavan / PIMS-päällikön TULEE arvioida sovellettavat lakisääteiset, toimialakohtaiset, finanssialan, kyberturvallisuutta koskevat, sopimusperusteiset, asiakas- ja palvelunsaajakohtaiset raportointikynnykset kunkin vaikutuksiltaan merkittävän henkilötietopoikkeaman osalta ja kirjata soveltuvuutta koskeva lopputulos REG01:een, REG08:aan ja REG10:een.

Näin MFA-hälytys muuttuu auditointikelpoiseksi näytöksi tietoturvan, tietosuojan ja vaatimustenmukaisuuden välillä.

NIS2, DORA ja GDPR: yksi poikkeama, eri kysymykset

MFA-väsymys on hyödyllinen eri vaatimusten välinen stressitesti, koska se koskettaa hallintoa, kyberhygieniaa, pääsynhallintaa, poikkeamien havaitsemista, toimittajien pääsyä ja tietoturvaloukkauksista ilmoittamista.

NIS2: johdon vastuu ja kyberhygienia

NIS2 koskee monia keskeisiä ja tärkeitä toimijoita sektorin, koon ja jäsenvaltion nimeämisen mukaan. Article 20 asettaa hallintoelimille vastuun hyväksyä kyberturvallisuuden riskienhallintatoimenpiteet, valvoa toteutusta ja saada koulutusta. Article 21 edellyttää asianmukaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien poikkeamien käsittely, kyberhygienia, toimitusketjun turvallisuus, pääsynhallinta, omaisuudenhallinta, koulutus sekä monivaiheinen tai jatkuva todennus soveltuvin osin. Article 23 tuo merkittäville poikkeamille vaiheistetut raportointivelvoitteet, mukaan lukien ennakkovaroituksen 24 tunnin kuluessa tietoon tulemisesta ja poikkeamailmoituksen 72 tunnin kuluessa.

Push bombing -poikkeamasta tulee siksi hallitustason kysymys: oliko MFA suunniteltu turvallisesti vai pelkästään otettu käyttöön?

DORA: todennus osana digitaalista häiriönsietokykyä

Soveltamisalaan kuuluville finanssialan toimijoille DORA:aa sovelletaan 17. tammikuuta 2025 alkaen. Se edellyttää TVT-riskien hallintaa, havaitsemista, reagointia, palautumista, poikkeamien raportointia, digitaalisen häiriönsietokyvyn testausta ja kolmansien osapuolten TVT-riskien hallintaa.

DORA Article 9 käsittelee suojaamista ja ehkäisemistä, mukaan lukien pääsynhallinta ja todennustoimenpiteet. Article 10 käsittelee poikkeavan toiminnan havaitsemista. Article 17 edellyttää TVT-poikkeamien hallintaprosessia. DORA-kontekstissa MFA-väsymystä koskevan todentavan aineiston tulee osoittaa, että vaikutuksen alaiset TVT-omaisuuserät tunnistettiin, seuranta havaitsi poikkeavan käyttäytymisen, poikkeama luokiteltiin vaikutuskriteerien perusteella, ylemmälle johdolle eskaloitiin tarvittaessa ja opit palautettiin TVT-riskienhallinnan viitekehykseen.

GDPR: käsittelyn turvallisuus ja osoitusvelvollisuus

GDPR Article 5(1)(f) edellyttää eheyttä ja luottamuksellisuutta. Article 5(2) edellyttää osoitusvelvollisuutta. Article 32 edellyttää riskiin nähden asianmukaista turvallisuutta. Article 4 määrittelee henkilötietojen tietoturvaloukkauksen turvallisuuden loukkaukseksi, joka johtaa henkilötietojen vahingossa tapahtuvaan tai lainvastaiseen tuhoamiseen, häviämiseen, muuttamiseen, luvattomaan luovuttamiseen tai pääsyyn henkilötietoihin.

Jos MFA-väsymys koskettaa henkilötietoja, näyttökysymys on yksinkertainen: pystyykö organisaatio osoittamaan asianmukaiset todennuskontrollit, seurannan, poikkeamiin reagoinnin ja tietoturvaloukkauksen arvioinnin?

Vastaavuustaulukko ISO-, NIST CSF 2.0-, COBIT 2019- ja auditointinäytölle

NIST CSF 2.0 on hyödyllinen, koska se muuntaa MFA-hallinnan GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-tuloksiksi.

COBIT 2019 lisää hallintoon selkeyttä. COBIT-suuntautunut auditoija voi tarkastella kohteita DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security ja MEA03 Managed compliance with external requirements. Painopiste ei ole MFA-toimittajassa. Kyse on siitä, tukeeko todennus liiketoimintatavoitteita, hallitaanko käyttöoikeuksia, onko seuranta tehokasta ja saako johto merkityksellistä varmuutta.

Koottu kartoitus auttaa vaatimustenmukaisuustiimejä välttämään pirstaleisia näyttöpyyntöjä:

Mitä auditoijat ja viranomaiset pyytävät

Vahvan MFA-väsymyksen hallintaohjelman tulee kestää useita auditointityylejä. Clarysecin Zenith Controls -vaatimustenmukaisuusopas osoittaa, miten ISO/IEC 27002:2022 -kontrolleja testataan ISO-, NIST-, COBIT- ja ISACA-menetelmien kautta.

Heikko ohjelma sanoo: ”Kysyimme käyttäjältä ja nollasimme salasanan.” Hallittu ohjelma tuottaa SIEM-hälytyksen, poikkeamatiketin, istunnon peruuttamista koskevan tallenteen, salasanan palauttamista koskevan todentavan aineiston, MFA-tekijän katselmoinnin, käyttöoikeuslokien analyysin, PII-arvioinnin, ilmoituskynnysten arvioinnin, juurisyyn kuvauksen, korjaavat toimenpiteet ja syötteen johdon katselmointiin.

30 päivän toimintasuunnitelma MFA-väsymyksen hallintaan

Tavoitteena ei ole täydellisyys 30 päivässä. Tavoitteena on näkyvyys, omistajuus ja todentava aineisto.

Viikko 1: tunnista ja rajaa soveltamisala

• Listaa kaikki identiteetintarjoajat, VPN:t, pilvikonsolit, SaaS-alustat ja etuoikeutetun pääsyn työkalut.
• Tunnista järjestelmät, joissa on henkilötietoja, taloustietoja, tuotantoympäristön käyttöoikeus tai palveluun vaikuttavia toimintoja.
• Vie nykyiset MFA-menetelmät ja poikkeukset.
• Tunnista ulkoiset ja toimittajien tilit.
• Lisää MFA-väsymys ja push bombing riskirekisteriin.
• Nimeä riskinomistaja ja käsittelytoimenpiteen omistaja.

Viikko 2: kovenna todennus

• Poista vanhentunut todennus käytöstä.
• Edellytä ylläpitäjiltä tietojenkalastelua kestävää MFA:ta, kun se on toteutettavissa.
• Ota käyttöön numerovastaavuus ja sovelluskonteksti push-MFA:ssa.
• Sovella ehdollista käyttöä sijainnin, laitteen vaatimustenmukaisuuden ja mahdottoman matkustuksen perusteella.
• Rajoita toistuvia push-kehotteita.
• Edellytä uudelleentodennusta korkean riskin toimille.
• Tee palvelutileistä ei-interaktiivisia, kun se on mahdollista.
• Dokumentoi poikkeukset päättymispäivän ja korvaavien kontrollien kanssa.

Viikko 3: seuraa ja harjoittele

• Varmista, että todennuslokit kattavat onnistumisen, epäonnistumisen, istunnon keston ja MFA-käytön.
• Luo hälytyssäännöt toistuville kehotteille, hylätyille kehotteille, joita seuraa hyväksyntä, uuden laitteen rekisteröinnille ja epätavalliselle sijainnille.
• Testaa hälytykset hallitulla simulaatiolla.
• Vahvista poikkeamatiketin luonti ja eskalointi.
• Kouluta käyttäjiä lyhyellä ”odottamaton MFA-kehote” -harjoituksella.
• Päivitä helpdesk-skriptit sosiaalisen manipuloinnin estämiseksi salasanan palautusten ja MFA:n uudelleenrekisteröinnin aikana.

Viikko 4: todentava aineisto ja johdon katselmointi

• Tallenna konfiguraatioviennit ja kuvakaappaukset.
• Kirjaa käyttöoikeuskatselmointien tulokset.
• Kytke koulutussuoritukset etuoikeutettuihin käyttäjiin.
• Katselmoi poikkeamat ja läheltä piti -tilanteet.
• Päivitä soveltuvuuslausunto ja riskienkäsittelysuunnitelma.
• Esitä jäännösriski ja mittarit johdolle.
• Aikatauluta sisäisen auditoinnin otanta.

Tee MFA-väsymyksestä auditoitavaa ennen kuin siitä tulee ilmoitettavaa

MFA-väsymys muistuttaa siitä, että tietoturvakontrollit pettävät saumakohdissa: identiteetin ja seurannan, politiikan ja koulutuksen, toimittajien ja sisäisen pääsyn sekä tietoturvapoikkeamiin reagoinnin ja tietosuojaraportoinnin välillä.

Organisaatiot, jotka hallitsevat tätä hyvin, eivät vain ”kytke MFA:ta päälle”. Ne hallitsevat todennusta elinkaarena, seuraavat sitä uhkasignaalina, kouluttavat käyttäjiä osana kontrollia ja säilyttävät todentavan aineiston osana ISMS:ää.

Clarysec kokoaa yhteen kolme kokonaisuutta:

• Zenith Blueprint: auditoijan 30 vaiheen tiekartta, erityisesti vaihe 19 turvallista todennusta varten, vaihe 22 todennustietoja varten ja vaihe 16 henkilöstölähtöistä poikkeamien ilmoittamista varten.
• Clarysecin politiikkamallit, mukaan lukien P38 Secure Communications and Multi-Factor Authentication (MFA) Policy, P22S Logging and Monitoring Policy - SME, P11S User Account and Privilege Management Policy - SME, Information Security Awareness and Training Policy - SME, PII Security and Access Control Policy ja PII Incident and Breach Management Policy.
• Zenith Controls: eri vaatimusten välinen opas, joka kartoittaa ISO/IEC 27002:2022 -kontrollit 5.17, 8.5, 8.15 ja 8.16 tukikontrolleihin, ISO-auditointiodotuksiin, GDPR:ään, NIS2:een, DORA:an, NISTiin ja COBITiin.

Jos olet tietoturvajohtaja, vaatimustenmukaisuuspäällikkö, auditoija tai liiketoimintavastuullinen, toteuta viikon mittainen MFA-väsymyksen todentavan aineiston katselmointi. Kerää MFA-konfiguraatio, todennuslokit, etuoikeutettujen käyttöoikeuksien luettelo, toimittajapääsyn luettelo, poikkeamien pelikirja, koulutusmateriaali ja poikkeusrekisteri. Jos nämä artefaktit eivät muodosta yhtä johdonmukaista kokonaisuutta, Clarysec voi auttaa rakentamaan kontrollipaketin ennen kuin hyökkääjä, auditoija tai viranomainen pyytää sitä.

Tutustu Zenith Blueprint -oppaaseen, katselmoi Zenith Controls tai varaa Clarysecin kartoituspuhelu, jotta MFA-väsymys muuttuu hallitustason yllätyksestä puolustettavaksi ja auditoitavaksi todennusohjelmaksi.