VPN:n MFA-pyyntö hylätty: mitä asiakasohjelman pitäisi tehdä

Hylätty MFA-pyyntö näyttää verkko-ongelmalta eikä ole sitä. Palvelin pyysi toista tekijää, tekijä palasi kielteisenä tai ei saapunut lainkaan, ja istunto evättiin ennen kuin mitään tunnelia oli olemassa. Se, mitä seuraavaksi tapahtuu, on asiakasohjelman käyttäytymiskysymys: tuodaanko virhe näkyviin ja annetaanko käyttäjän aloittaa puhdas yritys, vai yritetäänkö uudelleen tavalla, joka tuottaa lisää pyyntöjä ja lopulta laukaisee tilin suojauksen. Toinen polku on se, miten yksi väärin kirjoitettu koodi muuttuu lukituksi tiliksi.

Tarkista, mikä pyyntö epäonnistui

Aloita selvittämällä, mikä pyyntö epäonnistui. Push-ilmoitus, TOTP-koodi, FIDO-väite ja SAML-virta epäonnistuvat kukin eri tavalla, ja asiakasohjelma yleensä tietää, mitä se pyysi. Hylkäys, vanhentunut haaste ja toimitushäiriö, joka ei koskaan saavuttanut laitetta, päättyvät kaikki samaan yleiseen virheeseen, joten asiakasohjelman oma tila on usein ainoa paikka, jossa ero säilyy.

Tila kannattaa kirjata täsmällisesti. Kirjaa haasteen tunniste tai tapahtumaviite, tekijän tyyppi, aikaleima ja tulos, mutta ei koskaan koodia tai väitettä. Haasteen tunniste on se, jonka avulla ylläpitäjä löytää tapahtuman identiteetintarjoajan puolelta; ilman sitä tukikeskustelu alkaa sanoilla ”joskus viimeisen tunnin aikana” ja yleensä päättyy siihen. Käsittele sitä diagnostiikan metatietona, älä salaisuutena.

Yritä kerran uudelleen, tarkoituksella, uudella haasteella

Uudelleenyrityksen pitäisi olla uusi yritys uudella haasteella, ei vanhan toisto. Kun asiakasohjelma käyttää edellisen haasteen uudelleen, identiteetintarjoaja joko hylkää sen vanhentuneena tai, mikä on pahempaa, hyväksyy hyväksynnän, joka oli tarkoitettu aiemmalle yritykselle. Pyydä tuore haaste, näytä se ja anna käyttäjän toimia sen pohjalta, joka on juuri nyt näytöllä.

Kaksi yritystä lyhyellä tauolla on kohtuullinen oletus; rajoittamaton silmukka ei ole. Jos toinen yritys epäonnistuu samalla tavalla, pysähdy ja raportoi sen sijaan että jatkaisit.

Mitä asiakasohjelma ei saa tehdä

Asiakasohjelma ei saa tehdä useita asioita, jotka näyttävät hyödyllisiltä mutta eivät ole. Se ei saa jatkaa push-ilmoitusten lähettämistä, kunnes joku napauttaa hyväksy, koska se opettaa käyttäjiä hyväksymään pyyntöjä, joita he eivät aloittaneet, ja juuri siihen phishing-paketit luottavat. Se ei saa pudota heikompaan tekijään siksi, että vahva epäonnistui, eikä se saa poistaa palvelimen identiteettitarkistusta käytöstä päästäkseen ohi sertifikaattivalituksesta, joka ilmaantui samaan aikaan. Jokainen näistä kolmesta oikotiestä muuttaa tunnistautumisen epäonnistumisen tietoturvahäiriöksi.

Se ei saa myöskään niellä epäonnistumista hiljaa. Asiakasohjelma, joka sulkee yhteyden ja näyttää pyörivän osoittimen, jättää käyttäjän täysin tietämättömäksi siitä, pitäisikö yrittää uudelleen, odottaa vai soittaa tukeen. Näytä epäonnistuminen tekijän tyypin ja lyhyen koodin kanssa, pidä viesti vapaana salaisuuksista ja tee uudelleenyrityksestä nimenomainen toimi automaattisen sijaan.

Jos pyyntöä ei käynnistänyt näppäimistöllä oleva henkilö, oikea toimi on jättää se hylätyksi ja raportoida se vahvistettua tukipolkua pitkin. Pyynnön hyväksyminen melun lopettamiseksi on epäonnistumisen malli, ei korjaus.

Mitä tuelle kirjataan

Tuelle hyödyllinen kirjaus on pieni. Likimääräinen aika aikavyöhykkeineen, tili, asiakasohjelma ja versio, tekijän tyyppi sekä jokaisen yrityksen ei-salainen tila: pyydetty, hylätty, vanhentunut, hyväksytty mutta käytännön hylkäämä.

Pidä myös asiakasohjelman ja palvelimen kellot silmällä. TOTP on aikaikkunan tarkistus, joten kellonsa siirtänyt laite tuottaa kelvollisilta näyttäviä koodeja, jotka epäonnistuvat joka kerta, ja asiakasohjelma, joka raportoi virheellisestä koodista mainitsematta siirtymää, lähettää ihmiset nollaamaan tunnistetietoja, jotka eivät koskaan olleet väärin. Käyttäjän, jonka kirjautuminen epäonnistuu toistuvasti, pitäisi tarkistaa tuettu asiakasohjelman versio, rekisteröinnin tila ja dokumentoitu palautuspolku ennen uusien pyyntöjen luomista.

Palautuspolku ansaitsee saman huolen kuin kirjautumispolku. Kadonneen laitteen työnkulku on olemassa juuri siksi, että hylkäyksestä ei tulisi lupaa ohittaa tunnistautuminen, ja asiakasohjelman pitäisi linkittää organisaation dokumentoituun prosessiin sen sijaan että keksisi oman.

Sääntö, jonka varaan rakentaa, on että hylkäys on tulos, ei este. Raportoi se kerran, selkeästi, riittävällä kontekstilla toimimista varten, ja anna seuraavan yrityksen olla uusi. CISA:n ohjeet phishingiä kestävästä MFA:sta selittävät, miksi malli ”kysy kunnes hyväksytään” on vaarallinen alun alkaen, ja se on viite, joka kannattaa mainita, kun joku ehdottaa uudelleenyrityssilmukkaa. Kaiken, mitä asiakasohjelma lisää hylkäyksen jälkeen, pitäisi tehdä seuraavasta päätöksestä ihmiselle helpompi, ei poistaa päätöstä häneltä.