Pārvaldiet MFA nogurumu un pašpiegādes paziņojumu bombardēšanas uzbrukumus

Pašpiegādes paziņojums plkst. 2:13, kas kļuva par valdes jautājumu

Plkst. 2:13 vecākā finanšu administratore saņem mobilās ierīces paziņojumu: “Apstiprināt pieteikšanos?” Viņa ir pusmiegā, pieņem, ka tas ir noildzes paziņojums no mākoņvides finanšu platformas, un pieskaras “Apstiprināt”.

Plkst. 2:19 uzbrucējs jau ir identitātes pakalpojumu sniedzēja vidē. Plkst. 2:31 viņš mēģina piekļūt algu datu eksportam, priviliģētai mākoņvides konsolei un koplietotai pastkastei, ko izmanto piegādātāju maksājumiem. Plkst. 3:05 SOC redz atkārtotus MFA pieprasījumus, neierastu ģeogrāfisko atrašanās vietu, sekmīgu apstiprinājumu un jaunu sesiju no nepārvaldītas ierīces.

Rīta saruna ir pazīstama:

• “Bet mums bija MFA.”
• “Kāpēc lietotājs to apstiprināja?”
• “Vai mēs reģistrējām MFA pārbaudes informāciju?”
• “Vai tas ir personas datu aizsardzības pārkāpums?”
• “Vai mums ir 24 stundu vai 72 stundu ziņošanas pienākumi?”
• “Vai mūsu ISO 27001:2022 auditors to uzskatīs par kontroles pasākuma kļūmi?”
• “Vai tas ietekmē NIS2, DORA, GDPR, klientu līgumus vai kiberdrošības apdrošināšanu?”

Šī ir pārvaldības nepilnība, kas slēpjas aiz MFA noguruma un pašpiegādes paziņojumu bombardēšanas. Uzbrucēji nelauž kriptogrāfiju. Viņi izsmeļ cilvēka lēmumu pieņemšanas spēju, izmanto vāju autentifikācijas dizainu un meklē neuzraudzītus izņēmumus. Kontroles kļūme reti ir “MFA nav iespējota”. Parasti tā ir vāja identitātes apliecinājuma, riskanta pašpiegādes apstiprināšanas dizaina, trūkstošas numura atbilstības pārbaudes, neskaidru priviliģētās piekļuves noteikumu, nepietiekamas autentifikācijas žurnālfiksēšanas, vājas brīdinājumu sākotnējās izvērtēšanas, nepietiekami apmācītu lietotāju un dokumentētu pierādījumu trūkuma ķēde, kas neļauj pierādīt, ka organizācija ir pārskatījusi un novērsusi šo vājumu.

CISO, atbilstības vadītājiem, auditoriem un uzņēmumu īpašniekiem MFA nogurums jāuztver kā IDPS pierādījumu jautājums, nevis tikai kā identitātes pakalpojumu sniedzēja iestatījums. Risinājums apvieno ISO 27001:2022 riska apstrādi, ISO/IEC 27002:2022 kontroles pasākumus, politikas pienākumus, lietotāju informētību, incidentu reaģēšanu, piegādātāju pārvaldību un savstarpējos kartējumus ar NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT 2019.

MFA nogurums ir apliecinājuma nepilnība, nevis lietotāja problēma

MFA nogurums, ko dēvē arī par pašpiegādes paziņojumu bombardēšanu vai apstiprinājuma pieprasījumu bombardēšanu, rodas, kad uzbrucējs ar derīgu paroli atkārtoti izraisa MFA apstiprinājuma pieprasījumus, līdz lietotājs vienu no tiem pieņem. Dažkārt uzbrucējs pievieno sociālo inženieriju, piemēram, viltotu palīdzības dienesta zvanu, ziņu ar apgalvojumu “mēs testējam jūsu kontu” vai lūgumu apstiprināt pieteikšanos, lai apturētu paziņojumus.

Operacionālais risks ir tajā, ka organizācijas bieži uzskata visu MFA par līdzvērtīgu. Tā nav.

Vienkāršs “apstiprināt vai noraidīt” pašpiegādes paziņojums ir vājāks nekā numura atbilstības pārbaude, pret pikšķerēšanu noturīgas FIDO2 drošības atslēgas, uz sertifikātiem balstīta autentifikācija vai nosacītā piekļuve, kas bloķē neiespējamas pārvietošanās scenārijus un nepārvaldītas ierīces. MFA neizdodas arī tad, ja apiešanas izņēmumi nav dokumentēti, pakalpojumu konti ir interaktīvi, mantotie protokoli paliek atvērti vai augsta riska piekļuvei netiek prasīta spēcīgāka autentifikācija.

Zenith Blueprint: auditora 30 soļu ceļvedī Clarysec drošu autentifikāciju ietver posmā “Kontroles pasākumi darbībā”, 19. solī: “Tehnoloģiskie kontroles pasākumi I”. Norādījums ir tiešs:

Autentifikācija ir pirmā un viskritiskākā aizsardzības līnija starp apdraudējuma dalībnieku un jūsu sistēmām, datiem un pakalpojumiem. Ja autentifikācija ir vāja, visu pārējo — šifrēšanu, uzraudzību, segmentēšanu — var apiet.

Tas pats Zenith Blueprint 22. solī aplūko arī ISO/IEC 27002:2022 kontroles pasākumu 5.17:

Ja identitātes jautājums ir “Kas jūs esat?”, tad autentifikācija ir pierādījums. Kontroles pasākums 5.17 ir vieta, kur teorija satiekas ar uzticēšanos. Tas prasa, lai autentifikācijas informācija tiktu droši pārvaldīta visā tās dzīves ciklā, nodrošinot, ka metodes un autentifikācijas dati, ko izmanto identitātes pārbaudei, paši nekļūst par vājāko posmu.

Šie divi apgalvojumi izskaidro, kāpēc pašpiegādes paziņojumu bombardēšanai jābūt iekļautai Riska reģistrā. Šifrēšana nepalīdz, ja uzbrucējs kļūst par apstiprinātu lietotāju. Tīkla segmentēšana palīdz mazāk, ja priviliģēta mākoņvides piekļuve tiek apstiprināta noguruma radīta pieprasījuma dēļ. Uzraudzība darbojas tikai tad, ja autentifikācijas notikumi tiek žurnālfiksēti pietiekami detalizēti un ātri pārskatīti.

Nobriedušam riska formulējumam jābūt skaidram:

Šeit kļūst būtisks ISO 27001:2022. Standarts prasa kontekstu, ieinteresētās puses, līderību, risku izvērtēšanu, apstrādes plānošanu, darbības kontroli, uzraudzību, iekšējo auditu, vadības pārskatīšanu un nepārtrauktu uzlabošanu. MFA nogurums skar tos visus.

ISO 27001:2022 kontroles pasākumu kopa, ko pārbaudīs auditori

ISO 27001:2022 nodrošina pārvaldības sistēmas struktūru. ISO/IEC 27002:2022 nodrošina ieviešanas vadlīnijas kontroles pasākumiem. MFA noguruma un pašpiegādes paziņojumu bombardēšanas gadījumā auditori parasti koncentrēsies uz pasākumu kopu, nevis uz vienu kontroles pasākumu.

Clarysec Zenith Controls: savstarpējās atbilstības ceļvedis kartē ISO/IEC 27002:2022 kontroles pasākumu 8.5 Droša autentifikācija ar atbalstošiem kontroles pasākumiem, piemēram, 5.17 Autentifikācijas informācija, 8.2 Priviliģētās piekļuves tiesības, 8.16 Uzraudzības darbības, 5.24 Informācijas drošības incidentu pārvaldības plānošana un sagatavošanās un 5.34 Privātums un PII aizsardzība. Šī savstarpējā sasaiste ir būtiska, jo ekrānuzņēmums ar norādi “MFA iespējota” nav pietiekams. Auditori vēlas pierādījumus, ka autentifikācija ir projektēta, uzraudzīta, pārskatīta un uzlabota, pamatojoties uz risku.

Aizstāvamai pierādījumu paketei jāietver:

1. Risku izvērtēšana, kurā identificēta pašpiegādes paziņojumu bombardēšana un MFA pieprasījumu sociālā inženierija.
2. Autentifikācijas standarts, kas nosaka pieļaujamās MFA metodes pēc sistēmas kritiskuma.
3. Priviliģētās piekļuves politika, kas prasa spēcīgāku autentifikāciju administratora un attālinātai piekļuvei.
4. Identitātes pakalpojumu sniedzēja konfigurācijas eksports, kas parāda numura atbilstības pārbaudi, pieprasījumu ierobežojumus, nosacīto piekļuvi un bloķētu mantoto autentifikāciju.
5. Žurnāli, kas parāda sekmīgus un nesekmīgus MFA notikumus, noraidītus pieprasījumus, neiespējamas pārvietošanās gadījumus un ierīces kontekstu.
6. Brīdinājumu noteikumi atkārtotiem MFA pieprasījumiem, atkārtotām atteicēm un neierastam sekmīgam apstiprinājumam.
7. Incidentu reaģēšanas ieraksti par ar autentifikāciju saistītiem brīdinājumiem.
8. Informētības apmācību saturs, kas lietotājiem nosaka neapstiprināt negaidītus pieprasījumus.
9. Piekļuves tiesību pārskatīšanas ieraksti par priviliģētām un augstas ietekmes sistēmām.
10. Izņēmumu reģistrs ar beigu datumiem, Riska īpašnieka apstiprinājumiem un kompensējošiem kontroles pasākumiem.

Politika pārvērš “neapstipriniet negaidītus pieprasījumus” pierādījumos

Daudzas organizācijas norāda lietotājiem neapstiprināt aizdomīgus pieprasījumus. Šis padoms ir lietderīgs, taču ar to nepietiek ISO 27001:2022 sertifikācijai, NIS2 pārraudzībai, DORA noturībai, GDPR pārskatatbildībai, klientu sākotnējai izpētei vai kiberdrošības apdrošināšanai.

Pirmais politikas balsts ir P38 Drošas komunikācijas un daudzfaktoru autentifikācijas (MFA) politika. Tā tieši aptver cilvēkfaktoru:

Lietotāju informētība: lietotājiem jāsaņem apmācība, lai atšķirtu drošus un nedrošus komunikācijas kanālus. Apmācībai jāaptver pareiza daudzfaktoru autentifikācijas (MFA) izmantošana (piemēram, neapstiprinot negaidītus pieteikšanās pieprasījumus) un drošas komunikācijas prakse (piemēram, videokonferenču saišu pārbaude un konfidenciālu tēmu neapspriešana nedrošos sakaru kanālos).

Tas pārvērš MFA nogurumu par apmācības pienākumu, nevis vainošanas vingrinājumu. Tas ļauj CISO parādīt, ka apstiprinājuma pieprasījumu bombardēšana ir iekļauta ievadapmācībā, atkārtotajā apmācībā, uz lomām balstītā apmācībā un priviliģēto lietotāju instruktāžās.

Tā pati P38 Drošas komunikācijas un daudzfaktoru autentifikācijas (MFA) politika nosaka arī uzraudzības pienākumu:

Informācijas drošības funkcijai nepārtraukti jāuzrauga autentifikācijas žurnāli attiecībā uz jebkādiem vienfaktora pieteikšanās mēģinājumiem vai anomālām daudzfaktoru autentifikācijas (MFA) atteicēm. Drošas komunikācijas sistēmu žurnāli, ja piemērojams, jāuzrauga attiecībā uz nesankcionētas piekļuves mēģinājumiem vai konfigurācijas izmaiņām.

SME vajadzībām P11S Lietotāju kontu un privilēģiju pārvaldības politika - SME nosaka praktisku pamatlīmeni:

Daudzfaktoru autentifikācija (MFA) jāiespējo, ja tas ir tehniski iespējams, administratora kontiem vai sensitīvām sistēmām.

Frāze “ja tas ir tehniski iespējams” nekad nedrīkst kļūt par nepilnību. Ja sistēma neatbalsta spēcīgu MFA, izņēmums jāreģistrē ar īpašnieku, beigu datumu, kompensējošiem kontroles pasākumiem, uzraudzību un migrācijas plānu. Lielākas organizācijas to pašu gaidu var saskaņot ar P11 Lietotāju kontu un privilēģiju pārvaldības politiku un pēc tam pārbaudīt, vai politika un operacionālā realitāte sakrīt.

Atklāšanas pierādījumi izriet no P22S Žurnālfiksēšanas un uzraudzības politika - SME, kas prasa autentifikācijas notikumu žurnālfiksēšanu:

Autentifikācijas žurnāli: sekmīgi un nesekmīgi pieteikšanās mēģinājumi, sesijas ilgums, MFA izmantošana

Tā prasa arī steidzamu augsta riska autentifikācijas signālu pārskatīšanu:

Tūlītēja pārskatīšana pēc augstas smaguma pakāpes brīdinājumu atklāšanas (piemēram, ļaunatūra, nesekmīga daudzfaktoru autentifikācija (MFA), atkārtotas pieteikšanās atteices)

Informētībai jāattīstās līdz ar apdraudējumiem. Informācijas drošības informētības un apmācības politika - SME atbalsta šo ciklu:

Tēmām jāietver jauni riski (piemēram, pikšķerēšana), attiecīgās politikas izmaiņas un iekšējo incidentu tendences.

Kad SOC atklāj MFA noguruma mēģinājumus, šai izlūkošanas informācijai jānonāk lietotāju brīdinājumos, palīdzības dienesta skriptos, galda vingrinājumos un apmācību atjauninājumos.

Pārvaldīta MFA noguruma kontroles pasākumu pakete

Pieņemsim, ka jūsu organizācija izmanto mākoņvides identitātes pakalpojumu sniedzēju, SaaS CRM, finanšu platformu, VPN un pārvaldītu drošības pakalpojumu sniedzēju. Mērķis ir pārvaldīt MFA nogurumu, izmantojot Clarysec Zenith Blueprint, politiku bibliotēku un Zenith Controls savstarpējās atbilstības ceļvedi.

Sāciet ar Zenith Blueprint 19. soli, kurā komandām uzdots noteikt autentifikācijas prasības katrai sistēmai un brīdināts, ka autentifikācija tikai ar paroli jāizvairās administratora kontiem, mākoņvides konsolēm, attālinātās piekļuves rīkiem un internetam pieejamām sistēmām. Pēc tam piemērojiet praktisko pārskatīšanas darbību:

Pārskatiet savu MFA ieviešanu: identificējiet nepilnības un plānojiet to novēršanu. Validējiet, ka pakalpojumu konti, kur iespējams, nav interaktīvi, tiem ir droši autentifikācijas dati un tie ir dokumentēti. Apstipriniet, ka nevienā sistēmā vai lietojumprogrammā nav palikuši noklusējuma autentifikācijas dati.

Pārvērtiet šo norādījumu operacionālā kontroles pasākumu paketē.

1. solis: klasificējiet sistēmas pēc autentifikācijas riska

2. solis: noņemiet augsta riska pašpiegādes apstiprināšanas uzvedību

Administratora un augstas ietekmes kontiem atspējojiet pamata pašpiegādes apstiprināšanu. Kur iespējams, izmantojiet pret pikšķerēšanu noturīgus autentifikatorus. Ja pašpiegādes mehānisms paliek, piemērojiet numura atbilstības pārbaudi, lietojumprogrammas kontekstu, ģeogrāfisko kontekstu, ierīces piesaisti un pieprasījumu biežuma ierobežojumus. Bloķējiet mantoto autentifikāciju un riskantām sesijām pieprasiet atkārtotu autentifikāciju.

3. solis: definējiet brīdinājumu noteikumus MFA nogurumam

Praktiskam SIEM noteikumam jāaktivizējas, ja īsā laika periodā rodas viens vai vairāki no šiem modeļiem:

• Trīs vai vairāk MFA pašpiegādes pieprasījumi vienam lietotājam.
• Divi noraidīti pieprasījumi, kam seko viens apstiprināts pieprasījums.
• MFA apstiprinājums no jaunas ģeogrāfiskās atrašanās vietas vai nepārvaldītas ierīces.
• MFA pieprasījums pēc paroles izsmidzināšanas vai akreditācijas datu masveida izmēģināšanas signāla.
• MFA apstiprinājums priviliģētai piekļuvei ārpus ierastā darba laika.
• Jauna autentifikatora reģistrācija neilgi pēc nesekmīgiem pieteikšanās mēģinājumiem.

Brīdinājumam jāizveido incidenta pieteikums, jāinformē SOC vai drošības vadītājs un jāpieprasa ierobežošanas darbības: apturēt sesiju, atsaukt atjaunošanas marķierus, pieprasīt paroles atiestatīšanu, pārbaudīt ierīci, iztaujāt lietotāju, pārskatīt piekļuvi sesijas laikā un klasificēt, vai ir radusies ietekme uz personas datiem vai kritisku pakalpojumu.

4. solis: sasaistiet privātuma un incidentu ierakstus

Ja konts var piekļūt personas datiem, piemērojiet PII drošības un piekļuves kontroles politiku. Tā prasa spēcīgu autentifikāciju pirms augstas ietekmes PII piekļuves:

[Abos gadījumos] Informācijas drošības vadītājam PIRMS šādas piekļuves iespējošanas JĀPIEPRASA spēcīga autentifikācija priviliģētai, attālinātai, administratīvai vai augstas ietekmes PII piekļuvei un prasība jāreģistrē REG12.

Tā prasa arī definēt žurnālfiksēšanas tvērumu:

[Abos gadījumos] Sistēmas īpašniekam / Lietojumprogrammas īpašniekam PIRMS izmantošanas produkcijas vidē vai būtiskām izmaiņām JĀDEFINĒ PII žurnālfiksēšanas tvērums autentifikācijas notikumiem, piekļuves notikumiem, priviliģētām darbībām, PII eksportēšanas darbībām un būtiskām konfigurācijas izmaiņām REG12.

Ja uzraudzība norāda uz nesankcionētu PII piekļuvi, tā rada pienākumu izveidot incidenta ierakstu:

[Nosacīti] Incidentu reaģēšanas koordinatoram vienas darbdienas laikā JĀATVER vai JĀSAISTA REG10 ieraksts, ja uzraudzība norāda uz aizdomām par nesankcionētu PII piekļuvi, iespējamu PII izpaušanu, iespējamu PII izmainīšanu vai iespējamu PII pieejamības zudumu.

Privātuma eskalāciju noslēdz PII incidentu un personas datu aizsardzības pārkāpumu pārvaldības politika:

[Nosacīti] Privātuma vadītājam / PIMS vadītājam JĀIZVĒRTĒ piemērojamie tiesiskie, nozaru, finanšu sektora, kiberdrošības, līgumiskie, klientu un pakalpojumu saņēmēju ziņošanas trigeri katram augstas ietekmes PII incidentam un jāreģistrē piemērojamības rezultāts REG01, REG08 un REG10.

Tas pārvērš MFA brīdinājumu auditam gatavos pierādījumos drošības, privātuma un atbilstības jomās.

NIS2, DORA un GDPR: viens incidents, atšķirīgi jautājumi

MFA nogurums ir noderīgs savstarpējās atbilstības stresa tests, jo tas skar pārvaldību, kiberdrošības higiēnu, piekļuves kontroli, incidentu atklāšanu, piegādātāju piekļuvi un ziņošanu par pārkāpumiem.

NIS2: vadības pārskatatbildība un kiberdrošības higiēna

NIS2 attiecas uz daudzām būtiskām un svarīgām vienībām atkarībā no nozares, lieluma un dalībvalsts noteikšanas. Article 20 nosaka vadības struktūru pārskatatbildību apstiprināt kiberdrošības risku pārvaldības pasākumus, pārraudzīt ieviešanu un saņemt apmācību. Article 21 prasa atbilstošus tehniskos, darbības un organizatoriskos pasākumus, tostarp incidentu apstrādi, kiberdrošības higiēnu, piegādes ķēdes drošību, piekļuves kontroli, aktīvu pārvaldību, apmācību un daudzfaktoru vai nepārtrauktu autentifikāciju, kur tas ir piemēroti. Article 23 ievieš pakāpeniskus ziņošanas pienākumus nozīmīgiem incidentiem, tostarp agrīno brīdinājumu 24 stundu laikā pēc uzzināšanas un incidenta paziņojumu 72 stundu laikā.

Tāpēc pašpiegādes paziņojumu bombardēšanas incidents kļūst par valdes līmeņa jautājumu: vai MFA bija droši izstrādāta vai tikai iespējota?

DORA: autentifikācija kā digitālā darbības noturība

Attiecīgajām finanšu vienībām DORA piemēro no 2025. gada 17. janvāra. Tā sagaida IKT risku pārvaldību, atklāšanu, reaģēšanu, atjaunošanu, incidentu ziņošanu, digitālās darbības noturības testēšanu un IKT trešo pušu risku pārvaldību.

DORA Article 9 aplūko aizsardzību un prevenciju, tostarp piekļuves kontroli un autentifikācijas pasākumus. Article 10 aplūko anomālas darbības atklāšanu. Article 17 prasa ar IKT saistītu incidentu pārvaldības procesu. DORA kontekstā MFA noguruma pierādījumiem jāparāda, ka skartie IKT aktīvi tika identificēti, uzraudzība atklāja anomālu uzvedību, incidents tika klasificēts pēc ietekmes kritērijiem, augstākā vadība tika iesaistīta, kur tas bija nepieciešams, un gūtās mācības tika atgrieztas IKT riska ietvarā.

GDPR: apstrādes drošība un pārskatatbildība

GDPR Article 5(1)(f) prasa integritāti un konfidencialitāti. Article 5(2) prasa pārskatatbildību. Article 32 prasa riskam atbilstošu drošību. Article 4 personas datu aizsardzības pārkāpumu definē kā drošības pārkāpumu, kura rezultātā notiek personas datu nejauša vai nelikumīga iznīcināšana, zudums, izmainīšana, neatļauta izpaušana vai piekļuve tiem.

Ja MFA noguruma incidents skar personas datus, pierādījumu jautājums ir vienkāršs: vai organizācija var pierādīt atbilstošus autentifikācijas kontroles pasākumus, uzraudzību, incidentu reaģēšanu un pārkāpuma izvērtēšanu?

ISO, NIST CSF 2.0, COBIT 2019 un audita pierādījumu atbilstības kartējums

NIST CSF 2.0 ir noderīgs, jo pārvērš MFA pārvaldību rezultātos GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER.

COBIT 2019 pievieno pārvaldības skaidrību. Uz COBIT orientēts auditors var skatīt DSS05.04 Manage identity and logical access, DSS05 Manage security services, APO13 Managed security un MEA03 Managed compliance with external requirements. Uzmanības centrā nav MFA piegādātājs. Būtiski ir tas, vai autentifikācija atbalsta biznesa mērķus, vai piekļuves tiesības tiek pārvaldītas, vai uzraudzība ir efektīva un vai vadība saņem jēgpilnu apliecinājumu.

Konsolidēts kartējums palīdz atbilstības komandām izvairīties no sadrumstalotiem pierādījumu pieprasījumiem:

Ko prasīs auditori un regulatori

Spēcīgai MFA noguruma programmai jāiztur dažādi audita stili. Clarysec Zenith Controls savstarpējās atbilstības ceļvedis parāda, kā ISO/IEC 27002:2022 kontroles pasākumi tiek testēti ISO, NIST, COBIT un ISACA metodoloģijās.

Vāja programma saka: “Mēs pajautājām lietotājam un atiestatījām paroli.” Pārvaldīta programma sagatavo SIEM brīdinājumu, incidenta pieteikumu, sesijas atsaukšanas ierakstu, paroles atiestatīšanas pierādījumus, MFA faktora pārskatīšanu, piekļuves žurnālu analīzi, PII izvērtējumu, ziņošanas trigeru izvērtējumu, pamatcēloņa formulējumu, korektīvās darbības un ievadi vadības pārskatīšanai.

30 dienu rīcības plāns MFA noguruma pārvaldībai

Mērķis nav sasniegt pilnību 30 dienās. Mērķis ir redzamība, atbildība un pierādījumi.

1. nedēļa: identificējiet un nosakiet darbības jomu

• Uzskaitiet visus identitātes pakalpojumu sniedzējus, VPN, mākoņvides konsoles, SaaS platformas un priviliģētās piekļuves rīkus.
• Identificējiet sistēmas ar personas datiem, finanšu datiem, piekļuvi produkcijas videi vai pakalpojumu ietekmējošām funkcijām.
• Eksportējiet pašreizējās MFA metodes un izņēmumus.
• Identificējiet ārējos un piegādātāju kontus.
• Pievienojiet MFA nogurumu un pašpiegādes paziņojumu bombardēšanu Riska reģistram.
• Piešķiriet Riska īpašnieku un riska apstrādes īpašnieku.

2. nedēļa: cietiniet autentifikāciju

• Atspējojiet mantoto autentifikāciju.
• Kur iespējams, pieprasiet pret pikšķerēšanu noturīgu MFA administratoriem.
• Iespējojiet numura atbilstības pārbaudi un lietojumprogrammas kontekstu pašpiegādes MFA.
• Piemērojiet nosacīto piekļuvi atrašanās vietai, ierīces atbilstībai un neiespējamai pārvietošanai.
• Ierobežojiet atkārtotus pašpiegādes pieprasījumus.
• Pieprasiet atkārtotu autentifikāciju augsta riska darbībām.
• Kur iespējams, padariet pakalpojumu kontus neinteraktīvus.
• Dokumentējiet izņēmumus ar beigu termiņu un kompensējošiem kontroles pasākumiem.

3. nedēļa: uzraugiet un izmēģiniet

• Nodrošiniet, ka autentifikācijas žurnāli fiksē sekmīgus un nesekmīgus notikumus, sesijas ilgumu un MFA izmantošanu.
• Izveidojiet brīdinājumu noteikumus atkārtotiem pieprasījumiem, noraidītiem pieprasījumiem, kam seko apstiprinājums, jaunas ierīces reģistrācijai un neierastai atrašanās vietai.
• Testējiet brīdinājumus ar kontrolētu simulāciju.
• Validējiet incidenta pieteikuma izveidi un eskalāciju.
• Apmāciet lietotājus ar īsu vingrinājumu “negaidīts MFA pieprasījums”.
• Atjauniniet palīdzības dienesta skriptus, lai novērstu sociālo inženieriju paroles atiestatīšanas un MFA atkārtotas reģistrācijas laikā.

4. nedēļa: pierādījumi un vadības pārskatīšana

• Saglabājiet konfigurācijas eksportus un ekrānuzņēmumus.
• Reģistrējiet piekļuves tiesību pārskatīšanas rezultātus.
• Sasaistiet apmācību pabeigšanu ar priviliģētajiem lietotājiem.
• Pārskatiet incidentus un gandrīz notikušus gadījumus.
• Atjauniniet Piemērojamības paziņojumu un apstrādes plānu.
• Iesniedziet vadībai atlikušo risku un rādītājus.
• Ieplānojiet iekšējā audita izlasi.

Padariet MFA nogurumu auditējamu, pirms tas kļūst ziņojams

MFA nogurums atgādina, ka drošības kontroles pasākumi mēdz izgāzties savienojuma vietās: starp identitāti un uzraudzību, starp politiku un apmācību, starp piegādātājiem un iekšējo piekļuvi, starp incidentu reaģēšanu un privātuma ziņošanu.

Organizācijas, kas to pārvalda labi, ne tikai “ieslēdz MFA”. Tās pārvalda autentifikāciju kā dzīves ciklu, uzrauga to kā draudu signālu, apmāca lietotājus kā kontroles pasākuma daļu un saglabā pierādījumus kā IDPS daļu.

Clarysec apvieno trīs aktīvus:

• Zenith Blueprint: auditora 30 soļu ceļvedi, īpaši 19. soli drošai autentifikācijai, 22. soli autentifikācijas informācijai un 16. soli personāla vadītai incidentu ziņošanai.
• Clarysec politiku veidnes, tostarp P38 Drošas komunikācijas un daudzfaktoru autentifikācijas (MFA) politika, P22S Žurnālfiksēšanas un uzraudzības politika - SME, P11S Lietotāju kontu un privilēģiju pārvaldības politika - SME, Informācijas drošības informētības un apmācības politika - SME, PII drošības un piekļuves kontroles politika un PII incidentu un personas datu aizsardzības pārkāpumu pārvaldības politika.
• Zenith Controls: savstarpējās atbilstības ceļvedi, kas kartē ISO/IEC 27002:2022 kontroles pasākumus 5.17, 8.5, 8.15 un 8.16 ar atbalstošiem kontroles pasākumiem, ISO audita gaidām, GDPR, NIS2, DORA, NIST un COBIT.

Ja esat CISO, atbilstības vadītājs, auditors vai uzņēmuma īpašnieks, veiciet vienas nedēļas MFA noguruma pierādījumu pārskatīšanu. Iegūstiet savu MFA konfigurāciju, autentifikācijas žurnālus, priviliģētās piekļuves sarakstu, piegādātāju piekļuves sarakstu, incidentu rokasgrāmatu, apmācību materiālu un Izņēmumu reģistru. Ja šie artefakti neveido vienu saskaņotu stāstu, Clarysec var palīdzēt izveidot kontroles pasākumu paketi, pirms to pieprasa uzbrucējs, auditors vai regulators.

Izpētiet Zenith Blueprint, pārskatiet Zenith Controls vai ieplānojiet Clarysec ievadsarunu, lai pārvērstu MFA nogurumu no valdes līmeņa pārsteiguma par aizstāvamu, auditējamu autentifikācijas programmu.