Öruggt staðlað app
Upplýsingar um vöru
Tæknilýsing
- Vöruheiti: Safe App Standard CSA
- Útgáfa: 1.0
- Útgáfudagur: 10. janúar 2024
Um Standard
Safe App Standard CSA er sett af leiðbeiningum og best
venjur til að innleiða auðkenningaröryggiseftirlit í
farsímaforrit. Það miðar að því að tryggja örugga auðkenningu
kerfi og vernda viðkvæm gögn fyrir óviðkomandi aðgangi. The
staðallinn er þróaður í samráði við ýmsar stofnanir
og sérfræðingar á sviði netöryggis.
Tilgangur, umfang og fyrirhugaður markhópur
Tilgangur CSA Safe App Standard er að veita
þróunaraðilar með ráðleggingar og bestu starfsvenjur til innleiðingar
öruggar auðkenningarstýringar í farsímaforritum. Staðallinn
á við um þróunaraðila og stofnanir sem taka þátt í
þróun farsímaforrita sem krefjast auðkenningar. Það
er hannað til að auka heildaröryggi auðkenningarinnar
vinna úr og vernda friðhelgi notenda.
Tilkynning og leiðbeiningar fyrir þróunaraðila
Safe App Standard CSA veitir þróunaraðilum leiðbeiningar um
innleiða auðkenningaröryggiseftirlit. Það leggur áherslu á
mikilvægi þess að fylgja bestu starfsvenjum iðnaðarins og tryggja að
örugga framkvæmd auðkenningarleiða. Hönnuðir
ætti að vísa til staðalsins fyrir nákvæmar leiðbeiningar um framkvæmd
ráðlögð öryggiseftirlit.
Skjalaskilgreiningar og staðlaðar tilvísanir
Safe App Standard CSA inniheldur skjalaskilgreiningar og
staðlaðar tilvísanir sem gefa skýrleika um hugtök sem notuð eru
og vísa til annarra viðeigandi iðnaðarstaðla og leiðbeininga.
Hönnuðir ættu að vísa til þessara skilgreininga og tilvísana fyrir a
betri skilning á staðlinum.
Notkunarleiðbeiningar fyrir vöru
Auðkenning
Auðkenning er nauðsynlegur hluti af flestum farsímum
umsóknir. Það sannreynir auðkenni notenda, viðskiptavina,
forritum og tækjum áður en aðgangur er veittur að sérstökum
úrræði eða leyfa ákveðnar aðgerðir. Safe App Standard CSA
veitir ráðleggingar og bestu starfsvenjur til að innleiða örugga
auðkenningarstýringar.
Öryggiseftirlit
Safe App Standard CSA inniheldur eftirfarandi
auðkenningaröryggisstýringar:
| ID | Stjórna |
|---|---|
| AUTHN-BP01 | Forritið notar Multi-Factor Authentication (MFA) til að sannvotta áhættusöm viðskipti. |
| AUTHN-BP02 | Eftirlitslýsing |
| AUTHN-BP03 | Eftirlitslýsing |
| AUTHN-BP04 | Eftirlitslýsing |
| AUTHN-BP05 | Eftirlitslýsing |
| AUTHN-BP06 | Eftirlitslýsing |
AUTHN-BP01 – Fjölþátta auðkenning (MFA)
Í hefðbundnu einþátta auðkenningarkerfi, notendur
þarf venjulega aðeins að setja inn eitthvað sem þú veist (eins og notendanöfn
og lykilorð). Hins vegar bætir MFA við lög af sannprófun auðkennis
með því að krefjast viðbótarþátta eins og Something-You-Have og
Eitthvað-Þú-Ert. Þetta gerir það erfiðara fyrir illgjarna
leikara til að skerða reikninga og eykur heildaröryggi
auðkenningarferlið.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að innleiða Step-up MFA, sem krefst
viðbótar auðkenningarstig fyrir viðskipti með meiri áhættu. The
Safe App Standard CSA setur eftirfarandi MFA í forgang
samsetningar:
- Eitthvað-Þú-Veist
- Eitthvað-Þú-Át
- Eitthvað-Þú-Ert
Algengar spurningar (algengar spurningar)
Sp.: Hver er tilgangur CSA Safe App Standards?
A: Tilgangur CSA Safe App Standard er að veita
þróunaraðilar með ráðleggingar og bestu starfsvenjur til innleiðingar
öruggar auðkenningarstýringar í farsímaforritum.
Sp.: Hver er ætlaður markhópur fyrir Safe App CSA
Standard?
A: Safe App Standard CSA er ætlaður forriturum og
stofnanir sem taka þátt í þróun farsímaforrita
sem krefjast auðkenningar.
Sp.: Hverjir eru kostir þess að innleiða Multi-Factor
Authentication (MFA)?
A: Innleiðing MFA bætir við lögum af auðkennissannprófun, gerð
það er erfiðara fyrir illgjarna leikara að skerða reikninga og
auka heildaröryggi auðkenningarferlisins.
1
Safe App Standard útgáfa 1.0 frá CSA gefin út 10. janúar 2024
2
Í samráði við:
Samtök banka Singapúr, fastanefnd um netnefnd Deloitte Suðaustur-Asíu áhætturáðgjöf Ernst & Young ráðgjafar Pte. Ltd. KPMG í Singapúr Lazada Microsoft Singapore PricewaterhouseCoopers Risk Services Pte. Ltd.
Fyrirvari:
Samráð var haft við þessar stofnanir um staðalinn til að fá endurgjöf og athugasemdir við öryggiseftirlitið, lýsingu á öryggiseftirlitinu og tæknilegar útfærsluleiðbeiningar. Að því marki sem leyfilegt er samkvæmt lögum, skulu CSA og utanaðkomandi ráðgjafar ekki bera ábyrgð á ónákvæmni, villum og/eða aðgerðaleysi sem hér er að finna né fyrir neinu tapi eða tjóni af einhverju tagi (þar á meðal tapi á hagnaði, viðskiptum, viðskiptavild eða orðspori. , og/eða sérstakt, tilfallandi eða afleidd tjón) í tengslum við hvers kyns notkun eða traust á þessum staðli. Samtökum sem þróa farsímaforrit, þjónustuveitendum og þróunaraðilum er bent á að íhuga hvernig hægt sé að beita staðlinum við sérstakar aðstæður þeirra fá sína eigin lagalega og/eða tæknilega ráðgjöf í tengslum við innihald og/eða innleiðingu tilmælanna í staðalstofnunum sem þróa farsíma öpp, þjónustuveitendur og þróunaraðilar ættu að beita faglegu mati ef og þegar þeir innleiða tilmælin í staðlinum og ættu einnig að íhuga hvort frekari ráðstafanir séu nauðsynlegar í tengslum við sérstakar aðstæður þeirra.
3
Innihald
Í samráði við: ………………………………………………………………………………………………………………………… 3 Fyrirvari: … …………………………………………………………………………………………………………………………………………. 3 Um staðalinn……………………………………………………………………………………………………………………………… 6 Tilgangur, Umfang og fyrirhugaður markhópur ………………………………………………………………………………………… 6 Tilkynning og leiðbeiningar fyrir þróunaraðila ………………………… …………………………………………………………………………………. 7 Skjalaskilgreiningar og staðlaðar tilvísanir ……………………………………………………………………………… 8 1. Auðkenning ………………………………………… ………………………………………………………………………………………… 10
AUTHN-BP01 …………………………………………………………………………………………………………………………………. 11 AUTHN-BP01a ………………………………………………………………………………………………………………………………. 13 AUTHN-BP01b ………………………………………………………………………………………………………………………………. 14 AUTHN-BP01c……………………………………………………………………………………………………………………………….. 15
AUTHN-BP02 …………………………………………………………………………………………………………………………………. 16 AUTHN-BP03 …………………………………………………………………………………………………………………………………………. 17
AUTHN-BP03a ………………………………………………………………………………………………………………………………. 18 AUTHN-BP03b ………………………………………………………………………………………………………………………………. 19 AUTHN-BP04 …………………………………………………………………………………………………………………………………………. 20 AUTHN-BP05 …………………………………………………………………………………………………………………………………………. 21 AUTHN-BP06 …………………………………………………………………………………………………………………………………………. 22 ………………………………………………………………………………………………………………………………………………… ……….. 23 2. Heimild ………………………………………………………………………………………………………………………… ….. 24 AUTHOR-BP01 ………………………………………………………………………………………………………………………………… .. 25 AUTHOR-BP02 …………………………………………………………………………………………………………………………………. 26 AUTHOR-BP03 ………………………………………………………………………………………………………….. 27 AUTHOR-BP04 ………………………………………………………………………………………………………………………………….. 28 ………………………………………………………………………………………………………………………………………………………… …….. 29 3. Gagnageymsla (gögn í hvíld) ………………………………………………………………………………………………………… …. 30 GEYMSLA-BP01 …………………………………………………………………………………………………………………………………. 31 GEYMSLA-BP02 …………………………………………………………………………………………………………………………………. 32 GEYMSLA-BP02a …………………………………………………………………………………………………………………………………. 33 GEYMSLA-BP02b …………………………………………………………………………………………………………………………. 34 GEYMSLA-BP03 …………………………………………………………………………………………………………………………………. 35 ………………………………………………………………………………………………………………………………………………… ……….. 36 4. Anti-Tampeyrun og bakslagsvörn…………………………………………………………………………………………………..37 VIÐDRÆÐI-BP01 ………………… …………………………………………………………………………………………………………. 38 VIÐFRÆÐI-BP02 ………………………………………………………………………………………………………………………………. 39
4
SEIGLA-BP03 ………………………………………………………………………………………………………………………………. 41 SEIGLA-BP04 ………………………………………………………………………………………………………………………………………. 42 SEIGLA-BP05 ………………………………………………………………………………………………………………………………. 43 VIÐFRÆÐI-BP06 ………………………………………………………………………………………………………………………………………. 44 VIÐFRÆÐI-BP07 ………………………………………………………………………………………………………………………………. 45 Heimildir……………………………………………………………………………………………………………………………………………… 46
5
Um Standard
Inngangur Safe App Standard er ráðlagður staðall fyrir farsímaforrit (öpp), þróaður af Cyber Security Agency of Singapore (CSA), í samráði við samstarfsaðila iðnaðarins frá fjármálastofnunum, tæknistofnunum, ráðgjafafyrirtækjum og ríkisstofnunum. Yfirview Markmið staðalsins er að setja fram ráðlagða grunnlínu öryggisstýringa sem forritara og veitendur farsímaforrita geta farið eftir. Þetta myndi tryggja að öll staðbundin öpp fylgi sambærilegum öryggisstýringum fyrir farsímaforrit og hækkar þannig öryggisstig öppanna sem hýst eru og búin til í Singapúr.
Tilgangur, umfang og fyrirhugaður markhópur
Þetta skjal var þróað til að koma með ráðleggingar og tillögur til þróunaraðila til að aðstoða þá við að innleiða öryggisaðgerðir í öppin sín. Slíkar ráðleggingar og ábendingar miða að því að aðstoða þróunaraðila við að draga úr fjölmörgum netöryggisógnum og vernda forritin sín gegn nýjustu farsímasvindli og spilliforritum fyrir farsíma. Innihaldið hér er ekki bindandi, veitt án tillits til þess og ætlað að vera upplýsandi í eðli sínu og er ekki ætlað að bera kennsl á hugsanlegar netöryggisógnir tæmandi né tilgreina tæmandi ferli eða kerfi sem þróunaraðilar ættu að setja upp til að takast á við eða koma í veg fyrir slíkt. hótanir. Útgáfa 1 af leiðbeiningum og öryggisstýringum Safe App Standard mun einbeita sér fyrst og fremst að því að veita þróunaraðilum áhættusamra forrita öryggisleiðbeiningar til að vinna gegn nýjustu spilliforritum fyrir farsíma og svindl sem sést hafa í ógnarlandslagi Singapúr. Hins vegar geta þessar öryggisstýringar einnig gagnast og verið útfærðar af öðrum forritum. Mælt er með því að allir verktaki leitist við að innleiða þessar ráðstafanir til að auka öryggi farsímaforrita. Þrátt fyrir að þessi staðall hafi aðaláherslusvið, munu endurtekningar í framtíðinni stækka til að takast á við bestu starfsvenjur og leiðbeiningar um öryggisöryggi fyrir allan farsímaforritsbunkann.
6
Tilkynning og leiðbeiningar fyrir þróunaraðila
Um er að ræða lifandi skjal sem verður tekið til endurskoðunarview og endurskoðun reglulega. Eins og margir aðrir staðfestir staðlar, er Safe App Standard lifandi skjal sem verður reglulega uppfært til að passa við núverandi og þróun ógnarlandslags og nýja árásarvektora. Vinsamlegast vísað til CSA websíðuna til að vera uppfærð með nýjustu útgáfunni af Safe App Standard og laga öryggisráðstafanir og stýringar í samræmi við það. Lesa skal þennan staðal í samhengi við og kemur ekki í stað, breytir eða kemur ekki í stað laga, reglugerða eða annarra skyldur og skyldur forritara og veitenda forrita, þ. frammistöðustaðla eða skriflegar leiðbeiningar sem gefnar eru út samkvæmt þeim. Notkun þessa skjals og innleiðing á tilmælunum hér undanþágur heldur ekki eða leysir forritara og þjónustuaðila forritsins sjálfkrafa undan slíkum skyldum eða skyldum. Innihaldi þessa skjals er ekki ætlað að vera opinber yfirlýsing um lög eða koma í staðinn fyrir lögfræðilega eða aðra faglega ráðgjöf. Leiðbeiningar fyrir þróunaraðila um öryggisramma Safe App Standard Til að auðvelda notkun ættu verktaki að hafa í huga að útgáfa 2018 af Safe App Standard miðar að eftirfarandi mikilvægum sviðum og skjalinu sjálfu má skipta í eftirfarandi undirkafla:
· Auðkenning · Heimild · Gagnageymsla (Data-at-Rest) · Anti-Tamper & Anti-Reversing Þessi mikilvægu svæði eru innifalin til að tryggja stöðlun öryggi farsímaforrita gegn algengustu árásarvektorunum sem illgjarnir aðilar nota í vistkerfi okkar á staðnum. Safe App Standard veitir skýrt og hnitmiðað sett af öryggisstýringum, leiðbeiningum og bestu starfsvenjum til að auka öryggi farsímaforrita sem bjóða upp á eða gera áhættusamar viðskipti.
7
Skjalaskilgreiningar og staðlaðar tilvísanir
Skjalaskilgreiningar Eftirfarandi eru nokkrar skilgreiningar sem forritarar og lesendur ættu að hafa í huga þegar þeir nota þetta skjal: Viðkvæm gögn Notendagögn eins og persónugreinanlegar upplýsingar (PII) og auðkenningargögn eins og skilríki, dulkóðunarlyklar, einskiptis lykilorð, líffræðileg tölfræðigögn , öryggistákn, skírteini o.s.frv. Viðskipti með mikla áhættu eru þau sem fela í sér:
· Breytingar á fjármálastarfsemi sum tdampLesin innihalda en takmarkast ekki við skráningu á upplýsingum um viðtakanda þriðja aðila, hækkun á millifærslumörkum o.s.frv.
· Upphaf fjármálaviðskipta sum tdampinnihalda, en takmarkast ekki við, verðmætar fjármunafærslur, verðmætar millifærslur, kortafærslur á netinu, beingreiðsluaðgang, peningageymsluaðgerðir og áfyllingar o.s.frv.
· Breytingar á öryggisstillingum forritsins, sumar tdampLesið af þessu felur í sér en takmarkast ekki við að slökkva á auðkenningaraðferðum, uppfærslu stafrænna tákna eða skilríkja osfrv.
Öryggisstýringar Rekstrar- eða tækniráðstafanir sem mælt er með í þessu skjali sem ætti að innleiða til að stjórna, fylgjast með og draga úr hugsanlegum öryggisgöllum eða atvikum. Þessar öryggisstýringar hafa eftirfarandi auðkenni tengd við sig, td AUTHN-BP01, AUTHOR-BP01, STORAGE-BP01, RESILIENCE-BP01. Normative References Safe App Standard vísar til iðnaðarstaðla frá Open Web Umsóknaröryggisverkefni (OWASP), net- og upplýsingaöryggisstofnun Evrópusambandsins (ENISA) og gagnaöryggisstaðal fyrir greiðslukortaiðnað (PCI DSS). Tilvísunarlistinn er sem hér segir:
· MASVS frá OWASP (Mobile Application Security Verification Standard) · OWASP's MASTG (Mobile Application Security Testing Guide) · ENISA's Secure Development Guidelines (SSDG) · PCI DSS' Mobile Payment Acceptance Security Guidelines for Developers
8
9
1. Auðkenning
Inngangur
Auðkenning er nauðsynlegur hluti af flestum farsímaforritum. Þessi forrit nota venjulega ýmis konar auðkenningu, þar á meðal líffræðileg tölfræði, PIN-númer eða fjölþátta auðkenningarkóða. Að tryggja að auðkenningarkerfið sé öruggt og innleitt í samræmi við bestu starfsvenjur iðnaðarins er mikilvægt til að sannreyna auðkenni notenda.
Með því að innleiða öfluga öryggisstýringu fyrir auðkenningu geta verktaki tryggt að aðeins auðvottir notendur, viðskiptavinir, forrit og tæki geti fengið aðgang að tilteknum auðlindum eða framkvæmt ákveðnar aðgerðir. Með öruggum auðkenningarstýringum geta verktaki einnig dregið úr hættu á óviðkomandi gagnaaðgangi, viðhaldið heilleika viðkvæmra gagna, haldið uppi friðhelgi notenda og verndað heilleika áhættusamra viðskiptaaðgerða.
Stýringar í þessum flokki miða að því að mæla með auðkenningaröryggisstýringum sem forritið ætti að innleiða til að vernda viðkvæm gögn og koma í veg fyrir óviðkomandi aðgang. Það gefur einnig þróunaraðilum viðeigandi bestu starfsvenjur til að innleiða þessar öryggisstýringar.
öryggiseftirlit
ID
Stjórna
AUTHN-BP01 AUTHN-BP01a AUTHN-BP01b AUTHN-BP01c AUTHN-BP02 AUTHN-BP03 AUTHN-BP03a AUTHN-BP03b AUTHN-BP04 AUTHN-BP05 AUTHN-BP06
Notaðu Multi-Factor Authentication til að sannvotta áhættusamar færslur. Innleiða eitthvað sem þú veist auðkenningu sem einn af MFA þáttunum. Innleiða Something-You-Have auðkenningu sem einn af MFA þáttunum. Innleiða Something-You-Are auðkenningu sem einn af MFA þáttunum. Notaðu samhengisþætti til að sannvotta. Innleiða örugga lotuauðkenningu. Innleiða örugga staðfesta auðkenningu. Innleiða örugga ríkisfangslausa auðkenningu. Innleiða örugga lokun á lotu við útskráningu, óvirkni eða lokun forrits. Innleiða brute force vernd fyrir auðkenningu. Innleiða sannprófunarkerfi fyrir heiðarleika viðskipta.
10
AUTHN-BP01
Stjórna
Forritið notar Multi-Factor Authentication (MFA) til að sannvotta áhættusöm viðskipti.
Lýsing
Í hefðbundnu einþátta auðkenningarkerfi þurfa notendur venjulega aðeins að slá inn Something-YouKnow1 eins og notendanöfn og lykilorð. Hins vegar, ef þessi eini þáttur mistekst eða er í hættu, er allt auðkenningarferlið viðkvæmt fyrir ógnum.
MFA er auðkenningarferli sem bætir við lög af auðkennissannprófun, sem krefst ekki aðeins Eitthvað-Þú-Veist heldur líka Eitthvað-Þú-Have2 og Eitthvað-Þú-Ert3. Innleiðing MFA gerir það erfiðara fyrir illgjarna aðila að rýra reikningum og auka heildaröryggi auðkenningarferlisins.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að nota Step-up MFA. Það er ákveðin tegund af MFA þar sem appið inniheldur auðkenningarstefnu sem krefst viðbótar auðkenningarstigs, sérstaklega þegar reynt er að eiga viðskipti með meiri áhættu.
Hönnuðir ættu að forgangsraða eftirfarandi MFA samsetningum í röðinni 1, 2, 3 og 4, með valkost 1 sem öruggasta valið.
Þættir / Valkostur Eitthvað-Þú-Veist Eitthvað-Þú-Hefur
· Hugbúnaðarlykill · Vélbúnaðarlykill · SMS OTP Something-You-Are
1
2
3
4
1 Eitthvað-Þú-Veist vísar til upplýsinga sem notandinn veit, svo sem PIN (Personal Identification Number), lykilorð eða mynstur, o.s.frv. býr til auðkenningarskilríki, sem geta falið í sér tímabundin einstaks lykilorð (OTP). TdampMeðal slíkra tákna eru hugbúnaðartákn, vélbúnaðartákn og SMS OTP. 3 Something-You-Are vísar til líffræðileg tölfræðiauðkenni, þar sem einstök eðliseiginleikar notandans eru notaðir til sannprófunar, svo sem fingraför, sjónhimnuskannanir, andlitsgreiningu eða raddgreiningu.
11
Hönnurum er eindregið ráðlagt að reiða sig ekki á SMS og tölvupóst OTP sem rás fyrir auðkenningu fyrir viðskipti með mikla áhættu. Ef það er ekki hægt, er mikilvægt að innleiða líffræðileg tölfræðiþátt eða viðbótar auðkenningarþátt í tengslum við SMS OTP og tölvupóst OTP. Atriði sem þarf að hafa í huga
· Mælt er eindregið með því að velja staðbundnar lausnir þegar hægt er. · Hönnuðir ættu að tryggja að að minnsta kosti einn MFA þáttur sé sannreyndur hjá viðskiptavininum, með öllum
aðrir staðfestir á þjóninum. Í þeim tilfellum þar sem auðkenning er staðfest á biðlarahlið, sérstaklega fyrir Android, framfylgja TEE (Trusted Execution Environment) kóða sem byggir á. · Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
o OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 21.
o OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 51, 56. o MAS Technology Risk Management Guidelines (2021), bls. 34, 50. o ENISA Smartphone Secure Development Guidelines (2016), bls. 11.
12
AUTHN-BP01a Control Forritið útfærir Something-You-Know auðkenningu sem einn af MFA þáttunum. Lýsing Eitthvað-Þú-Veist táknar grundvallarlag af auðkennissannprófun sem felur í sér upplýsingar sem notandinn þekkir, svo sem PIN-númer (Personal Identification Number), lykilorð, mynstur, osfrv. Innleiðing á Something-You-Know sem einn af MFA-þáttunum grunnstig auðkenningar með því að krefjast þess að notendur gefi upp einstakar upplýsingar sem tengjast reikningum sínum. Það er afgerandi þáttur í meginreglunni um „Eitthvað-Þú-Veist, Eitthvað-Þú-Have og Eitthvað-Þú-Ert,“ sem stuðlar að alhliða og skilvirkri fjöllaga öryggisstefnu. Leiðbeiningar um innleiðingu Hönnuðir ættu að samþykkja eftirfarandi leiðbeiningar við að búa til sterk og örugg lykilorð:
· Gakktu úr skugga um að lágmarkslengd lykilorðs sé 12 stafir eða meira. · Hafa blöndu af hástöfum og lágstöfum, tölustöfum og sértáknum sem takmarkast við
~`! @#$%^&*()_-+=:;,.? Hönnuðir ættu einnig að viðurkenna og forðast algengar gildrur við að búa til lykilorð:
· Forðastu að nota ágiskanleg orð, orðasambönd eða samsetningar. · Forðastu að fella inn persónulegar upplýsingar. · Forðastu raðstafi (td „123456“) eða endurtekna stafi (td „aaaaa“). Atriði sem þarf að hafa í huga · Hönnuðir ættu aðeins að framfylgja skiptum á skilríkjum á skipulagseignir eða ef það er engin
MFA innleiðing á notendaenda, td breytt árlega eða samkvæmt viðeigandi tímaramma. · Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin
veittar í: o MAS Technology Risk Management Guidelines (2021), bls. 34. o ENISA Smartphone Secure Development Guidelines (2016), bls. 10.
13
AUTHN-BP01b Control Forritið útfærir Something-You-Have auðkenningu sem einn af MFA þáttunum. Lýsing Something-You-Have krefst þess að notendur auðkenni með líkamlegu tæki, forriti eða tákni sem býr til auðkenningarskilríki, sem geta falið í sér tímabundin einstaks lykilorð (OTP). TdampMeðal slíkra tákna eru hugbúnaðartákn, vélbúnaðartákn og SMS OTP. Að innleiða eitthvað sem þú hefur sem einn af MFA þáttunum eykur flókið auðkenningarferlið með því að krefjast eignar á áþreifanlegum þætti, sem dregur verulega úr líkum á óviðkomandi aðgangi. Það er afgerandi þáttur í meginreglunni um „Eitthvað-Þú-Veist, Eitthvað-ÞúHave og Eitthvað-Þú-Ert,“ sem stuðlar að alhliða og áhrifaríkri fjöllaga öryggisstefnu. Leiðbeiningar um framkvæmd. Hönnuðir ættu að nota tímabundið OTP fyrir hugbúnaðartákn, vélbúnaðartákn og SMS OTP. Fylgja skal eftirfarandi leiðbeiningum:
· OTP ætti aðeins að gilda í ekki meira en 30s. · OTP sem er rangt slegið inn eftir 3 tilraunir ætti að vera ógilt og fundur notandans
ætti að afturkalla eða hafna. Atriði sem þarf að hafa í huga
· Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 56-57. o MAS Technology Risk Management Guidelines (2021), bls. 50, 51. o ENISA Smartphone Secure Development Guidelines (2016), bls. 10.
14
AUTHN-BP01c
Stjórna Forritið útfærir Something-You-Are auðkenningu sem einn af MFA þáttunum.
Lýsing Something-You-Are krefst þess að notendur auðkenni með líffræðilegum tölfræðiauðkennum eins og fingraförum, sjónhimnuskönnun eða andlitsgreiningu. Að innleiða Something-You-Are sem einn af MFA þáttunum bætir við mjög persónulegum og erfitt að endurtaka auðkenningarþátt. Það veitir öflugri leið til að sannreyna auðkenni notenda en þættir sem þú veist eitthvað og eitthvað sem þú hefur, sem dregur úr hættu á óviðkomandi aðgangi. Það er afgerandi þáttur í meginreglunni um „Eitthvað-Þú-Veist, Eitthvað-Þú-Have, og Eitthvað-ÞúAre,“ sem stuðlar að alhliða og áhrifaríkri fjöllaga öryggisstefnu. Leiðbeiningar um innleiðingu Hönnuðir ættu að innleiða líffræðilega tölfræðilega auðkenningu á miðlara með því að nota traustan líffræðilegan auðkenningarvettvang eins og Singpass. Hins vegar, ef það er ekki framkvæmanlegt, ættu verktaki að innleiða líffræðileg tölfræði auðkenningu viðskiptavinar í gegnum traustar framkvæmdaumhverfi (TEE) tækisins eins og CryptoObject og Android Protected Confirmation fyrir Android eða Keychain þjónustu fyrir iOS. Atriði sem þarf að hafa í huga
· Hönnuðir ættu að takmarka virkni forrita á tækjum sem vantar traust framkvæmt umhverfi (TEE) eða líffræðileg tölfræði. Til dæmisampÍ öðru lagi er hægt að greina Android tæki sem skortir TEE með því að nota „isInsideSecureHardware“ Android API.
· Hönnuðir ættu að ógilda líffræðilega tölfræði auðkenningu ef breytingar verða á líffræðileg tölfræðikerfi, eins og að skrá nýtt fingrafar á tækið. Bæði iOS og Android pallar styðja að stilla dulritunarlykil forrits til að renna út til að bregðast við slíkum breytingum.
· Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 227233, 422-426. o MAS Technology Risk Management Guidelines (2021), bls. 51. o ENISA Smartphone Secure Development Guidelines (2016), bls. 11, 26.
15
AUTHN-BP02
Stjórnun Forritið notar samhengisbundna þætti til að sannvotta. Lýsing Samhengisbundnir þættir kynna kraftmikla þætti eins og staðsetningu notanda og eiginleika tækja. Þó að MFA veiti öflugt lag af öryggi með því að krefjast margra auðkenningarþátta, skapar samhengisþættir umfangsmeira og aðlagandi auðkenningarferli sem getur boðið upp á viðbótarávinning við að takast á við vaxandi áhættu af óviðkomandi aðgangi. Innleiðing samhengisbundinna þátta lágmarkar að treysta á kyrrstæðar persónuskilríki, sem gerir það erfiðara fyrir illgjarna aðila að reyna óviðkomandi aðgang. Leiðbeiningar um innleiðingu Hönnuðir ættu að íhuga eftirfarandi samhengisþætti til að sannreyna auðkenni notanda:
· Geolocation: Leyfa aðgang byggt á raunverulegri staðsetningu tækis með því að nota GPS, Wi-Fi eða IP tölu landfræðilega staðsetningu.
· Gerð tækis: Leyfa aðgang byggt á eiginleikum tækis. td skjástærð getur ákvarðað hvort tæki er snjallsími eða spjaldtölva.
Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 56, 58. · ENISA leiðbeiningar um örugga þróun snjallsíma (2016), bls. 11.
16
AUTHN-BP03
Stjórna Forritið útfærir örugga lotuauðkenningu. Lýsing Örugg lotuauðkenning tryggir öfluga lotustjórnun fyrir bæði staðbundna og ríkislausa auðkenningu. Illa stýrðar lotur, óháð því hvort appið fylgir stateful4 eða stateless5 auðkenningaraðferðum, getur leitt til öryggisógna eins og óviðkomandi aðgangs, loturæningja eða gagnabrota. Innleiðing á öruggri lotuauðkenningu fyrir staðbundna fundi notar örugg lotuauðkenni, dulkóðuð samskipti og rétta tímamörk til að koma í veg fyrir óviðkomandi aðgang. Fyrir ríkisfangslausa auðkenningu tryggir það að tákn séu tamper-ónæmir, viðheldur auðkenningarheilleika án þess að treysta á geymslu á miðlara. Leiðbeiningar um innleiðingu Hönnuðir ættu að innleiða örugga lotuauðkenningu með því að samþykkja eftirfarandi bestu starfsvenjur fyrir staðbundna (AUTHN-BP03a) og ríkislausa (AUTHN-BP03b) auðkenningaraðferðir fyrir lotur. Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 51-55. · Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 51. · Leiðbeiningar um örugga þróun ENISA snjallsíma (2016), bls. 10.
4 Staðfest auðkenning vísar til stjórnun lotuástanda á miðlarahlið, sem venjulega krefst notkun setuauðkennis. 5 Ríkisfangslaus auðkenning vísar til stjórnun lota án þess að geyma notendatengdar upplýsingar á netþjóninum.
17
AUTHN-BP03a Control Forritið útfærir örugga auðkenningu. Lýsing Örugg staðbundin auðkenning felur í sér að vernda og viðhalda viðvarandi lotum. Þó að staðbundin auðkenning veiti óaðfinnanlega notendaupplifun í gegnum viðvarandi notendalotur, getur hún verið viðkvæm fyrir ýmsum öryggisógnum, svo sem illgjarna gerendur sem reyna að stela lotuauðkennum. Innleiðing á öruggri staðbundinni auðkenningu verndar notendareikninga fyrir óviðkomandi aðgangi og hugsanlegum veikleikum sem tengjast lotustjórnun án þess að skerða jafnvægið milli notagildis og öryggis. Leiðbeiningar um framkvæmd. Hönnuðir ættu að bera kennsl á endapunkta miðlara sem afhjúpa viðkvæmar upplýsingar eða mikilvægar virkni. Hönnuðir ættu einnig að samþykkja eftirfarandi staðbundna sannvottunaraðferðir:
· Hafna beiðnum með týndum eða ógildum lotuauðkennum eða táknum. · Búðu til lotuauðkenni af handahófi á þjóninum án þess að bæta þeim við URLs. · Bættu öryggi lotuauðkenna með réttri lengd og óreiðu, sem gerir giska erfitt. · Skiptu aðeins um lotuauðkenni yfir öruggar HTTPS tengingar. · Forðastu að geyma lotuauðkenni í viðvarandi geymslu. · Staðfestu lotuauðkenni fyrir notandaaðgang að forréttindaþáttum forrita. · Slíta fundum á þjóninum, eyða upplýsingum um lotu þegar tíminn rennur út eða útskrá. Athugasemdir Ef þú ert í vafa skaltu íhuga að nota trausta auðkenningarpalla og samskiptareglur. Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 52.
18
AUTHN-BP03b Control Forritið útfærir örugga ríkisfangslausa auðkenningu. Lýsing Örugg ríkisfangslaus auðkenning felur í sér öruggar táknaðferðir fyrir skilvirka og stigstærða auðkenningu. Þó að ríkisfangslaus auðkenning veiti ávinning, getur hún verið viðkvæmari fyrir öryggisógnum eins og að vera notandi ef tákn eru ekki tryggilega mynduð, send og geymd. Innleiðing á öruggri ríkisfangslausri auðkenningu tryggir að sérhver auðkenningartákn sé meðhöndluð á öruggan hátt á meðan ávinningurinn er af skilvirkni og sveigjanleika, sem dregur úr hættu á óviðkomandi aðgangi. Leiðbeiningar um innleiðingu Hönnuðir ættu að samþykkja eftirfarandi bestu starfsvenjur fyrir ríkisfangslausar setuauðkenningar:
· Búðu til tákn á netþjóninum án þess að bæta þeim við URLs. · Auka öryggi tákna með réttri lengd og óreiðu, sem gerir giska erfitt. · Skiptu aðeins um tákn um öruggar HTTPS tengingar. · Staðfestu að engin viðkvæm gögn, eins og PII, séu felld inn í tákn. · Forðastu að geyma tákn í viðvarandi geymslu. · Staðfestu tákn fyrir notandaaðgang að forréttindaþáttum forrita. · Loka táknum á miðlarahlið, eyða upplýsingum um tákn þegar tíminn rennur út eða útskrá. · Undirritaðu dulrita tákn með því að nota öruggt reiknirit, forðast notkun núll algrím. Athugasemdir · Ef þú ert í vafa skaltu íhuga að nota trausta auðkenningarpalla og samskiptareglur. · Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin
veitt í: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 52-53.
19
AUTHN-BP04
Stjórnun Forritið útfærir örugga lokun á lotu við útskráningu, óvirkni eða lokun forrits. Lýsing Örugg lokun á lotu tryggir skilvirka lokun notendalota. Í atburðarásum eins og útskráningu, óvirkni eða lokun forrita er möguleiki fyrir illgjarna aðila að nýta sér alla langvarandi aðgangsstaði ef fundum er ekki stjórnað á viðeigandi hátt. Með því að innleiða örugga lokun lotu við útskráningu, óvirkni eða lokun forrita getur það dregið verulega úr hættu á óviðkomandi aðgangi með því að slíta notendalotum sjálfkrafa og vernda notendaupplýsingar frá því að óviðkomandi aðilar fái aðgang að þeim. Leiðbeiningar um útfærslu Hönnuðir ættu að sannvotta notendur á ný eftir útskráningu, aðgerðaleysi í forriti, aðgerðaleysi, bakgrunn, algjöran tímafrest eða skyndilega/þvingaða lokun. Hönnuðir ættu einnig að búa til ný lotuauðkenni á þjóninum í hvert sinn sem notendur fara upp á nýtt auðkenningarstig til að koma í veg fyrir festingu setu. Atriði sem þarf að hafa í huga
· Hönnuðir ættu að tryggja að lokun lotunnar feli í sér að hreinsa eða aflétta öllum staðbundnum táknum eða lotuauðkennum.
· Hönnuðir ættu að ákvarða aðgerðalaus tímamörk út frá áhættu og eðli fjármálaþjónustu.
· Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í: o OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 55-56, 58. o MAS Technology Risk Management Guidelines (2021), bls. 51. o ENISA Smartphone Secure Development Guidelines (2016), bls. 11.
20
AUTHN-BP05
Stjórnun Forritið útfærir grimmdarvörn fyrir auðkenningu. Lýsing Árásir á grimmdarkrafti fela í sér sjálfvirkar og kerfisbundnar tilraunir til að giska á notendaskilríki, tdample, með því að prófa ýmsar samsetningar af notendanöfnum og lykilorðum til að fá óviðkomandi aðgang. Rute force vernd takmarkar fjölda innskráningartilrauna innan tiltekins tímabils. Að innleiða brute force vernd fyrir auðkenningu getur dregið verulega úr hættu á óviðkomandi aðgangi, verndað notendareikninga og viðhaldið heiðarleika auðkenningarferlisins. Leiðbeiningar um innleiðingu Hönnuðir ættu að innleiða grófa krafta með eftirfarandi bestu starfsvenjum:
· Innleiða athuganir gegn sjálfvirkni. · Notaðu takmörkun á gjaldskrá fyrir innskráningartilraunir. · Settu inn stigvaxandi tímatafir (td 30 sekúndur, 1 mínúta, 2 mínútur, 5
mínútur) fyrir innskráningartilraunir. · Framfylgja lokun reikninga. Atriði sem þarf að hafa í huga · Hönnuðir ættu að hafa í huga að allar MFA-aðferðir eru viðkvæmar fyrir ofbeldi. · Hönnuðir ættu að koma á framfæri ástæðum fyrir lokun reiknings og veita aðgengilegar leiðir
fyrir notendur að auðkenna sig og fjarlægja læsingu. TdampMeðal þess er að hringja í hjálparsíma eða nota líffræðilega tölfræðilega sannprófun. · Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í:
o ENISA snjallsímaþróunarleiðbeiningar (2016), bls. 10, 16.
21
AUTHN-BP06
Stjórnun Forritið innleiðir sannprófunarkerfi fyrir heiðarleika viðskipta. Lýsing Þó að auðkenning tryggi auðkenni notandans, útilokar það ekki möguleikann á sviksamlegum athöfnum meðan á færsluferlinu stendur. Sannprófunaraðferðir á heiðarleika viðskipta eru aukaöryggisaðgerðir sem gefa notendum tíma og tæki til að bregðast við hugsanlegum svikum. Innleiðing sannprófunarkerfis fyrir heiðarleika viðskipta tryggir að hver viðskipti gangist undir ítarlega skoðun til að staðfesta nákvæmni og áreiðanleika þeirra. Leiðbeiningar um innleiðingu Hönnuðir geta innleitt eftirfarandi tillögur að bestu starfsvenjum:
· Hefja færslu sannprófun/staðfestingarsímtal. · Gefðu rauntíma viðskiptasögu. · Innleiða kælingartíma frá 12 klukkustundum til 24 klukkustunda. · Slökkva á erlendum viðskiptum sjálfgefið; virkja aðeins í gegnum MFA. Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 57-58.
22
23
2. Heimild
Inngangur
Heimildaröryggi starfar í tengslum við auðkenningaröryggi. Heimildaöryggi í farsímaforritum er afgerandi varnarlína þar sem það afmarkar hverjir geta nálgast hvaða auðlindir innan apps. Það býr til kerfisbundnar stýringar og staðfestir aðgangsrétt notenda innan apps.
Hönnuðir geta tryggt að aðeins viðurkenndir notendur, viðskiptavinir, forrit og tæki hafi aðgang að sérstökum tilföngum eða framkvæmt ákveðnar aðgerðir með því að innleiða öfluga heimildastýringu og heimildaruppsetningar. Með leyfisstýringum geta þróunaraðilar einnig dregið úr hættu á óviðkomandi gagnaaðgangi, viðhaldið heilleika viðkvæmra gagna, haldið uppi friðhelgi notenda og verndað heilleika áhættuviðskiptaaðgerða. Þó að framfylgja þessara aðferða verði að vera á ytri endapunktinum, er það jafn mikilvægt fyrir forritið á viðskiptavininum að fylgja viðeigandi bestu starfsvenjum til að tryggja örugga notkun viðkomandi heimildasamskiptareglna.
Stýringar í þessum flokki veita heimildaröryggisstýringar sem appið ætti að innleiða til að vernda viðkvæm gögn og koma í veg fyrir óviðkomandi aðgang. Það gefur einnig þróunaraðilum viðeigandi bestu starfsvenjur um hvernig eigi að innleiða þessar öryggisstýringar.
öryggiseftirlit
ID
Stjórna
AUTHOR-BP01 Innleiða heimild á netþjóni.
AUTHOR-BP02 Innleiða heimild viðskiptavinar með tækjabindingu.
AUTHOR-BP03 Látið notendur vita um allar nauðsynlegar heimildir áður en þeir byrja að nota appið.
HÖFUNDUR-BP04
Látið notendur vita um öll áhættusöm viðskipti sem hafa verið heimilað og lokið.
24
HÖFUNDUR-BP01
Stjórnun Forritið útfærir heimild á netþjóni. Lýsing Heimild á netþjóni vísar til að staðfesta og veita aðgangsheimildum til notenda eða forrita af netþjóni eða heimildaþjóni. Þetta tryggir að ákvörðunum og heimildum um aðgangsstýringu sé stjórnað og framfylgt á netþjóninum frekar en biðlaranum. Með því að innleiða heimild á netþjóni minnka verktaki tækifærum fyrir illgjarna árásarmenn í tamper eða framhjá öryggisráðstöfunum í forritinu til að fá óviðkomandi aðgang að viðkvæmum gögnum (þ.e. PII og auðkenningargögn). Leiðbeiningar um innleiðingu Hönnuðir ættu að innleiða heimild á netþjóni eftir að auðkenning hefur gengið vel, áður en aðgangsheimildir eru veittar. Hönnuðir ættu að tryggja að notendum sé veittur aðgangur á grundvelli eftirfarandi:
· Úthlutað hlutverki með heimildum: Tryggja að notendur geti aðeins framkvæmt verkefni sem tengjast ábyrgð þeirra.
· Samhengisþættir: Dýnamísk aðgangssvið eins og Aðgangstími og Atferlisgreining.
Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 50-55, 58. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), bls. 10. · ENISA Smartphone Secure Development Guidelines (2016), bls. 10-11.
25
HÖFUNDUR-BP02
Stjórnun Forritið innleiðir heimild viðskiptavinar með tækjabindingu.
Lýsing
Heimild viðskiptavinarhliðar er ferlið við að stjórna aðgangsheimildum innan farsímaforrits. Þetta er áhættusamt þar sem að treysta á viðskiptavininn getur afhjúpað forrit fyrir varnarleysi eins og óviðkomandi aðgang og hugsanleg svik.
Ef viðskiptaaðgerðir forrits (td að stofna hugbúnaðartákn) krefjast heimilda viðskiptavinarhliðar, er mælt með tækjabindingu (öryggisaðferð sem tengir heimildir til að fá aðgangsréttindi á tilteknu tæki). Með því að innleiða tækjabindingu geta forrit staðfest auðkenni tækisins og komið á trausti. Þetta dregur úr áhættu sem tengist óviðkomandi aðgangi og viðheldur öruggri, traustri leið milli tækja, forrita og netþjóna.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að koma á tengingu milli forrita og tækisins þegar auðkenni notanda er notað í fyrsta skipti á óskráðu fartæki.
Hönnuðir ættu einnig að staðfesta að forrit:
· Athugaðu hvort breytingar hafi verið á tækinu frá síðasta keyrslutíma. · Athugaðu hvort breytingar séu á auðkennismerkjum tækisins. · Athugaðu hvort tækið sem keyrir appið sé í öruggu ástandi (td engin flóttabrot eða rætur). Ofangreind eru bara nokkur examples af bestu starfsvenjum sem notuð eru af iðnaðinum. Eftir því sem vistkerfi fartækja þróast geta þessar aðferðir orðið úreltar. Sem slíkir ættu verktaki að fylgjast vel með nýjustu bestu starfsvenjum iðnaðarins til að sannreyna tengingar tækja. Atriði sem þarf að hafa í huga
Til að staðfesta tæki á Android tækjum geta verktaki:
· Fáðu einstök auðkenni eins og IMEI eða Android auðkenni. · Sæktu byggingarupplýsingar. · Nýttu innfædda OS API eiginleika, eins og öryggisnet Google.
Til að staðfesta tæki á iOS tækjum geta verktaki:
· Nýttu innbyggða stýrikerfisþjónustu, eins og auðkenni Apple tækis í gegnum UIDevice.
Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 316-317, 516. · MAS Technology Risk Management Guidelines (2021), bls. 51, 56.
26
HÖFUNDUR-BP03
Stjórnun Forritið lætur notendur vita um allar nauðsynlegar heimildir áður en þeir byrja að nota forritið. Lýsing Nauðsynlegar heimildir eru tiltekin réttindi og getu sem appið biður um frá farsímanum. Þessar heimildir skilgreina hvaða auðlindir eða virkni appið hefur aðgang að í tækjum notenda. Sumt fyrrvampinnihalda, en takmarkast ekki við, myndavél, hljóðnema, staðsetningu o.s.frv. Með því að innleiða viðeigandi tilkynningar sem upplýsa notendur um hvaða heimildir er beðið um geta verktaki komið í veg fyrir að notendur veiti ómeðvitað of miklar heimildir, sem getur gert illgjarnum aðilum kleift að nýta sér veikleika. og stela viðkvæmum gögnum (þ.e. PII og Authentication Data). Slíkar tilkynningar munu einnig gera notendum kleift að taka upplýstar ákvarðanir um forritin sem þeir setja upp. Leiðbeiningar um framkvæmd. Hönnuðir ættu að nota viðvaranir í forriti (í appi) til að biðja notendur um aðgangsheimild. Hönnuðir ættu einnig að tryggja að tilkynningar/viðvaranir birti ekki viðkvæm gögn. Atriði sem þarf að hafa í huga. Hönnuðir ættu aðeins að biðja um nauðsynlegar heimildir fyrir virkni appsins. Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 56, 58. · ENISA leiðbeiningar um örugga þróun snjallsíma (2016), bls. 8, 18, 28. · Apple Developer Guide on Privacy, https://developer.apple.com/design/human-interface-
leiðbeiningar/næði (jan 2024). · Handbók Android þróunaraðila um persónuvernd, https://developer.android.com/quality/privacy-and-
öryggi (jan 2024).
27
HÖFUNDUR-BP04
Stjórnun Forritið lætur notendur vita um öll áhættusöm viðskipti sem hafa verið samþykkt og lokið.
Lýsing Ef app er með áhættusama viðskiptavirkni ætti að láta notendur vita strax þegar færslu hefur verið heimilað og lokið. Með því að innleiða þessa stjórnun geta verktaki tryggt að notendum sé gert strax ljóst þegar áhættusamar færslur hafa verið heimilar og lokið svo að þeir geti greint hugsanleg svikaviðskipti eins fljótt og auðið er.
Leiðbeiningar um útfærslu Hönnuðir ættu að nota eftirfarandi aðferðir til að gera notendum viðvart:
· Viðvaranir í forriti (í forriti). · Tilkynningar í tölvupósti. · Short Message Service (SMS) tilkynningar. Hönnuðir ættu einnig að tryggja að tilkynningar/viðvaranir birti ekki viðkvæm gögn.
Ofangreind eru bara nokkur examples af bestu starfsvenjum tilkynningatækni sem notuð er af iðnaðinum. Eftir því sem vistkerfi fartækja þróast geta þessar aðferðir orðið úreltar. Sem slíkir ættu verktaki að fylgjast vel með nýjustu bestu starfsvenjum iðnaðarins til að tilkynna notendum um áhættusamar viðskipti sem eru heimilaðar og lokið.
Atriði sem þarf að hafa í huga. Hönnuðir ættu aðeins að biðja um nauðsynlegar heimildir fyrir virkni appsins.
Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 52. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), bls. 10. · ENISA Smartphone Secure Development Guidelines (2016), bls. 8. · Apple Developer Guide on Privacy, https://developer.apple.com/design/human-interface-
leiðbeiningar/næði (jan 2024). · Handbók Android þróunaraðila um persónuvernd, https://developer.android.com/quality/privacy-and-
öryggi (jan 2024).
28
29
3. Gagnageymsla (Data-at-Rest)
Inngangur
Öryggi gagnageymslu fyrir gögn í hvíld snýr að því að standa vörð um heilleika og trúnað viðkvæmra gagna (þ.e. PII og auðkenningargagna) sem eru geymd á staðnum á tækja- og forritaþjónshlið viðskiptavinar þegar þau eru ekki notuð eða send. Þetta nær yfir bestu starfsvenjur, verndarráðstafanir og dulkóðunartækni sem notuð er til að tryggja gögn sem geymd eru í gagnagrunnum, files, skyndiminni, minni og Trusted Execution Environment (TEE) á farsímum og svipuðum svæðum á netþjónum forrita.
Hönnuðir geta tryggt að notendagögn séu varðveitt og vernduð með því að innleiða öflugt öryggiseftirlit til að geyma gögn í hvíld. Rétt eftirlit með gögnum í hvíld tryggir einnig að appið geti dregið úr hættu á óviðkomandi aðgangi, málamiðlun tækis, hugsanlegum gagnabrotum og gagnaleka og styrkt varnir appsins.
Eftirfarandi stýringar tryggja að öll viðkvæm gögn sem forritið geymir af ásettu ráði séu vernduð á fullnægjandi hátt, óháð því hvar markmiðið er. Það nær einnig yfir óviljandi leka vegna óviðeigandi notkunar á API eða kerfisgetu.
öryggiseftirlit
ID
Stjórna
STORAGE-BP01 Geymdu viðkvæm gögn sem eru aðeins nauðsynleg fyrir viðskipti.
STORAGE-BP02 Innleiða örugga geymslu á viðkvæmum gögnum.
STORAGE-BP02a Geymdu viðkvæm gögn á öruggan hátt á miðlarahlið.
GEYMSLA-BP02b
Geymdu viðkvæm gögn á öruggan hátt á viðskiptavininum í traustu framkvæmdaumhverfi (TEE).
STORAGE-BP03 Eyddu viðkvæmum gögnum þegar þau eru ekki lengur nauðsynleg.
30
GEYMSLA-BP01
Stjórnun Appið geymir viðkvæm gögn sem eru aðeins nauðsynleg fyrir viðskipti. Lýsing Viðkvæm gögn eru skilgreind sem notendagögn (PII) og auðkenningargögn (td skilríki, dulkóðunarlyklar o.s.frv.) Hönnuðir ættu aðeins að geyma viðkvæm gögn sem eru nauðsynleg fyrir starfsemi apps. Söfnun óþarfa upplýsinga eykur áhrif hugsanlegra öryggisbrota, sem gerir app að aðlaðandi skotmarki illgjarnra leikara. Með því að innleiða þessa öryggisstýringu geta verktaki tryggt að útsetning sé takmörkuð við þau gögn sem krafist er fyrir sérstakar viðskiptaaðgerðir, sem lágmarkar áhrifin ef óviðkomandi aðgangur eða gagnabrot er að ræða. Leiðbeiningar um framkvæmd. Hönnuðir ættu að flokka gögn sem appið notar út frá næmni stofnunarinnar og út frá lagaskilyrðum. Hönnuðir ættu að samþykkja eftirfarandi leiðbeiningar til að tryggja gögn sem eru flokkuð sem viðkvæm:
1. Innleiða örugga geymslulausn byggða á næmni hennar á biðlarahlið/miðlarahlið. 2. Beita gagnaverndarráðstöfunum (td auðkenningu, hass með salti, dulkóðun) 3. Eyddu viðkvæmum gögnum þegar þau eru ekki lengur nauðsynleg. Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í: · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 190, 398. · MAS Technology Risk Management Guidelines (2021), bls. 9-10, 36, 38. · ENISA Smartphone Secure Development Guidelines (2016), bls. 6.
31
GEYMSLA-BP02
Stjórnun Forritið útfærir örugga geymslu á viðkvæmum gögnum. Lýsing Örugg geymsla fyrir farsímaforrit vísar til innleiðingaraðferða og venja til að vernda viðkvæm gögn sem eru geymd á fartækjum og netþjónum forrita gegn óheimilum aðgangi, þjófnaði eða þjófnaði.ampering. Þetta felur í sér bestu starfsvenjur eins og dulkóðun, hashing, auðkenningu og rétta aðgangsstýringu. Með því að innleiða örugga geymslu geta verktaki dregið úr óviðkomandi aðgangi, málamiðlun tækja, hugsanlegum gagnabrotum og gagnaleka. Leiðbeiningar um innleiðingu Hönnuðir ættu að innleiða örugga geymslulausn sem er í samræmi við viðkvæmni gagna. Hönnuðir ættu einnig að forgangsraða eftirfarandi röð fyrir örugga geymslulausn (frá viðkvæmustu gögnunum til minnst viðkvæmustu gagna):
1. Server-hlið (öll viðkvæm gögn ættu að vera geymd á miðlara-hlið). 2. Biðlarahlið innan trausts framkvæmdaumhverfis (í því tilviki þar sem miðlarahlið er það ekki
mögulegt, geymdu öll viðkvæm gögn í TEE-hlið viðskiptavinarins). Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 17-18. · OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 190-203, 398-
406. · ENISA Smartphone Secure Development Guidelines (2016), bls. 06-07.
32
GEYMSLA-BP02a
Stjórna
Forritið geymir viðkvæm gögn á öruggan hátt á miðlarahlið.
Lýsing
Með því að geyma viðkvæm gögn á netþjóninum er átt við að geyma gögn á ytri netþjónum eða gagnagrunnum forrita. Slík nálgun skapar betra umhverfi til að vernda gögn gegn óviðkomandi aðgangi eða brotum, gerir kleift að tryggja öruggari aðgangsstýringu, möguleika til að innleiða betri öryggisráðstafanir eins og flóknari dulkóðun og ákvæði um hraðari öryggisuppfærslur.
Með því að innleiða geymslu á viðkvæmum gögnum á miðlarahlið geta verktaki dregið úr þeirri áhættu sem felst í gagnageymslu viðskiptavinar, þar sem geymsla viðskiptavinarhliðar er í eðli sínu næmari fyrir gagnageymsluaðferðum sem almennt eru notuð af illgjarnum aðilum í farsímasvindli.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að beita að minnsta kosti einni af eftirfarandi gagnaverndarráðstöfunum:
1. Aðeins fyrir lykilorð geta forritarar notað hashing með salt6. Í stað þess að geyma raunveruleg lykilorð eru einstök sölt búin til og sameinuð lykilorðum, sem búa til saltað kjötkássa.
2. Hönnuðir geta dulkóðað7 viðkvæm gögn með dulkóðunarstöðlum eins og AES-128. 3. Hönnuðir geta innleitt auðkenni8 með sjálfstýrðri auðkenningu eða auðkenni
þjónustu, skipta viðkvæmum gögnum út fyrir tákn þar sem hægt er. Að auki ættu þróunaraðilar að tryggja að auðkenning sé nægilega löng og flókin (studd af öruggri dulritun) byggt á gagnanæmi og viðskiptaþörfum.
Ofangreind eru bara nokkur examples af bestu starfsvenjum sem iðnaðurinn notar. Eftir því sem vistkerfi fartækja þróast geta þessar bestu starfsvenjur orðið úreltar. Sem slíkir ættu verktaki að fylgjast með nýjustu bestu starfsvenjum iðnaðarins til að geyma viðkvæm gögn á öruggan hátt á netþjóninum.
Atriði sem þarf að hafa í huga
Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 19-20. · OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 71-77, 219-227,
416-421. · Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 30, 36-37, 39. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), bls. 9. · Leiðbeiningar um örugga þróun ENISA snjallsíma (2016), bls. 6-9.
6 Hashing með salti er notað til að bæta við auknu öryggislagi með því að gera það reikningsfrekt fyrir árásarmenn að ráða upprunaleg viðkvæm gögn. Í samhengi við geymslu lykilorðs eða afleiðslu lykla ættu verktaki að nota einhliða lykilafleiðsluaðgerðir eða hægfara kjötkássa reiknirit, svo sem PBKDF2, bcrypt eða scrypt. 7 Dulkóðun er notuð til að umbreyta gögnum í ólesanlegt snið, sem tryggir að jafnvel þótt þau séu opnuð án heimildar, haldist viðkvæm gögn trúnaðarmál. 8 Táknun er notuð til að skipta viðkvæmum gögnum út fyrir tákn til að lágmarka hættuna á útsetningu fyrir viðkvæmum gögnum.
33
GEYMSLA-BP02b
Stjórna
Forritið geymir viðkvæm gögn á öruggan hátt á viðskiptavininum í traustu framkvæmdaumhverfi (TEE).
Lýsing
Trusted Execution Environment (TEE) er einangrað svæði innan vélbúnaðar eða örgjörva arkitektúrs farsíma sem veitir mjög öruggt umhverfi til að geyma viðkvæm gögn og framkvæma viðkvæmar eða mikilvægar aðgerðir. Það er hannað til að vernda viðkvæm gögn, dulmálslykla og mikilvæga ferla fyrir óviðkomandi aðgangi eða t.ampering. Ef viðskiptaaðgerðir apps krefjast geymslu á viðkvæmum gögnum á skjólstæðingsmegin er mælt með því að geyma þau í TEE tækisins.
Með því að innleiða rétta geymslu á viðkvæmum gögnum í TEE viðskiptavinarhliðinni geta verktaki dregið úr ógnum sem stafar af tæki sem er í hættu og frá utanaðkomandi illgjarnum aðilum. Slík geymsla getur einnig dregið úr óviðkomandi aðgangi að viðkvæmum gögnum notanda í appi og komið í veg fyrir að dulkóðunarlykla sé stolið.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að geyma viðkvæm gögn á öruggan hátt á viðskiptavininum í traustu framkvæmdaumhverfi (TEE) eins og TrustZone frá Android ARM, Secure Enclave frá Apple.
Hönnuðir ættu einnig að geyma að minnsta kosti eftirfarandi lista yfir viðkvæm gögn í TEE:
· Líffræðileg tölfræði auðkenni. · Auðkenningarmerki. · Dulmálslyklar í öruggu lyklastjórnunarkerfi eins og Android Keystore, iOS
Lyklakippa.
Ofangreind eru bara nokkur examples um hvaða viðkvæm gögn forritarar ættu að geyma í TEE. Eftir því sem vistkerfi fartækja þróast ættu verktaki að nýta sér frelsi til að geyma öll gögn sem þeir telja nauðsynleg til að geyma í TEE.
Atriði sem þarf að hafa í huga
Fyrir tæki án TEE vélbúnaðar geta verktaki íhugað notkun sýndargerðra TEEs.
Að öðrum kosti geta forritarar íhugað að slökkva á appinu eða slökkva á áhættuviðskiptaaðgerðum appsins, þar sem appið er talið óöruggt fyrir áhættusamar færslur.
Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 19-20. · OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 75, 93, 194-200. · Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 51. · PCI Mobile Payment Acceptance Security Guidelines v2.0.0 (2017), bls. 07-09, 14. · ENISA Smartphone Secure Development Guidelines (2016), bls. 10.
34
GEYMSLA-BP03
Stjórna
Forritið eyðir viðkvæmum gögnum þegar það er ekki lengur nauðsynlegt.
Lýsing
Með því að eyða viðkvæmum gögnum er átt við ferlið við að fjarlægja eða eyða varanlega trúnaðargögnum, einkagögnum eða viðkvæmum gögnum úr geymslutækjum, netþjónum eða gagnagrunnum. Þetta ferli tryggir að viðkvæm gögn séu fjarlægð með óafturkræfum hætti og ekki er hægt að nálgast þær, ná í þær, afhjúpa fyrir slysni eða endurgera þær af óviðkomandi einstaklingum eða með gagnabataaðferðum.
Með því að innleiða þetta ferli geta verktaki lágmarkað gluggann þar sem árásarmenn geta nýtt sér veikleika til að stela viðkvæmum gögnum.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að nota eftirfarandi viðvarandi geymsluöryggistækni:
· Hreinsaðu vistaðar vafrakökur þegar forriti er lokað eða notaðu vafrakökugeymslu í minni. · Fjarlægðu öll viðkvæm gögn við fjarlægingu apps. · Fjarlægðu allan gagnagrunn handvirkt files sem innihalda viðkvæm gögn (td iOS WebView skyndiminni) frá
the file kerfi þegar tengdar viðskiptaaðgerðir hætta að vera til.
Ofangreind eru bara nokkur examples af bestu starfsvenjum sem iðnaðurinn notar. Eftir því sem vistkerfi fartækja þróast geta þessar aðferðir orðið úreltar. Sem slíkir ættu verktaki að fylgjast með nýjustu bestu starfsvenjum iðnaðarins til að eyða viðkvæmum gögnum þegar þau eru ekki lengur nauðsynleg.
Atriði sem þarf að hafa í huga
Hönnuðir ættu að hafa í huga að fylgja almennt viðurkenndum stöðlum og viðeigandi lögum um varðveislu gagna, þar á meðal en ekki takmarkað við:
· Persónuverndarlög (PDPA) · General Data Protection Regulation (GDPR) · The Payment Card Industry Data Security Standard (PCI DSS)
Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 199, 206-214, 403-414.
· Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 39. · ENISA Smartphone Secure Development Guidelines (2016), bls. 07, 09-10.
35
36
4. Anti-Tampering & Anti-Reversing
Inngangur
Andstæðingur-Tampöryggisstýringar og öryggisstýringar gegn viðsnúningi eru viðbótarráðstafanir sem þróunaraðilar geta innleitt til að vinna gegn árásum sem reyna aðamper eða öfugt forrit. Með því að innleiða báða eiginleikana bæta forritarar mörgum lögum af vörnum við forrit, sem gerir illgjarna leikara erfiðara fyrir að ná árangri.amper eða öfugt forrit, sem gæti leitt til:
· Þjófnaður eða málamiðlun á verðmætum viðskiptaeignum eins og séralgrími, viðskiptaleyndarmálum eða viðkvæmum gögnum,
· Fjárhagslegt tjón notenda sem nota appið til áhættusamra viðskipta, · Fjárhagslegt tap stofnana vegna tekjumissis eða málaferla, · Skaða á orðspori vörumerkis vegna neikvæðrar umfjöllunar eða óánægju viðskiptavina
Stjórntækin tryggja að forrit keyra á traustum kerfum, koma í veg fyrir tamping á keyrslutíma og tryggja heilleika virkni forritanna. Að auki hindra stjórntækin skilning með því að gera árásarmönnum erfitt fyrir að átta sig á hvernig öppin virka.
öryggiseftirlit
ID
Stjórna
RESILIENCE-BP01 Skilti með vottorðum frá opinberum app verslunum.
RESILIENCE-BP02 Innleiða flótta-/rótskynjun. RESILIENCE-BP03 Settu upp keppinautaskynjun.
RESILIENCE-BP04 Innleiða uppgötvun gegn spilliforritum.
RESILIENCE-BP05 Settu inn krókavörn.
RESILIENCE-BP06 Útfærsla yfirbygging, fjarstýrð viewing og mótvægisaðgerðir á skjámyndum.
VIÐDRÆÐI-BP07
Innleiða andstæðingur-ásláttur handtaka eða anti-keylogger gegn þriðja aðila sýndarlyklaborð.
37
VIÐDRÆÐI-BP01
Stjórna
Forritið er kóða undirritað með vottorðum frá opinberum appverslunum.
Lýsing
Forritum er oft falsað af illgjarnum leikurum og þeim er dreift í gegnum rásir sem ekki eru strangar reglur. Að undirrita app með vottorðum frá opinberum appverslunum tryggir farsímastýrikerfinu og notendum að farsímaforritið sé frá staðfestum uppruna.
Innleiðing kóðaundirritunar hjálpar stýrikerfum að ákvarða hvort leyfa eigi hugbúnaði að keyra eða setja upp byggt á undirskriftum eða vottorðum sem notuð eru til að undirrita kóðann. Þetta hjálpar til við að koma í veg fyrir uppsetningu og framkvæmd hugsanlega skaðlegra forrita. Að auki hjálpar kóðaundirritun einnig við sannprófun á heiðarleika, þar sem undirskriftir munu breytast ef appið hefur verið t.amperuð með.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að kóða undirrita forritin sín með vottorðum. Þessi hluti veitir tdamples um hvernig á að gera þetta í gegnum tvo vinsælustu pallana iOS og Android.
Fyrir Apple App Store er hægt að gera það með því að skrá sig í Apple Developer Program og búa til beiðni um undirritun vottorðs í þróunargáttinni. Hönnuðir geta skráð sig í Apple Developer Program og geta vísað í eftirfarandi þróunarhandbók fyrir kóðaundirskrift undir atriði sem þarf að hafa í huga.
Fyrir Android eru ýmsar App verslanir. Fyrir Play Store Google er hægt að gera það með því að stilla Play App Signing sem er skilyrði fyrir dreifingu í gegnum Google Play Store. Fyrir frekari upplýsingar um hvernig á að gera það geta forritarar farið í Android forritarahandbókina undir atriði sem þarf að hafa í huga.
Fyrir aðrar opinberar verslanir, skoðaðu viðkomandi leiðbeiningar um þróunaraðila um undirritun frumkóða forrita. Athugasemdir Þetta öryggiseftirlit er einnig skilyrði fyrir birtingu forrita í opinberum forritaverslunum, sem slík eru ráðleggingar um að forritið þitt sé undirritað með kóða með vottorðum frá opinberum forritaverslunum. Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· Apple Developer Program Guide for Code Signing, https://developer.apple.com/support/code-signing (janúar 2024).
· Handbók Android þróunaraðila um persónuvernd, https://developer.android.com/quality/privacy-andsecurity (janúar 2024).
· OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 325-326, 522523.
· Leiðbeiningar um örugga þróun ENISA snjallsíma (2016), bls. 21.
38
VIÐDRÆÐI-BP02
Stjórna
Forritið útfærir jailbreak eða rótargreiningu.
Lýsing
Rótuð og jailbroken tæki eru almennt talin óörugg. Rótuð eða jailbroken tæki gera notendum kleift að öðlast aukin réttindi, sem gerir auðveldara að sniðganga öryggis- og stýrikerfistakmarkanir. Slík aukin réttindi geta verið óörugg fyrir öpp þar sem þessi réttindi gera illgjarnum aðilum kleift að nýta sér veikleika, stela skilríkjum, taka yfir notendatæki og framkvæma sviksamleg forritaviðskipti.
Með því að innleiða flóttabrot eða rótargreiningu geta verktaki komið í veg fyrir að ofangreind hetjudáð gerist, verndað hugverk forrita, tryggt stöðugleika forrita og komið í veg fyrir að kerfi í forriti fari framhjá.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að innleiða jailbreak eða rótargreiningu með því að innleiða eftirfarandi athuganir í appinu sínu fyrir Android tæki:
1. Athugaðu fyrir ofurnotanda eða SU tvöfaldur. 2. Finndu rót file kerfisbreytingar. 3. Leitaðu að forritum með rætur. 4. Athugaðu fyrir sérsniðna bata. 5. Athugaðu hvort óörugg API notkun er.
Hönnuðir ættu að innleiða jailbreak eða rótargreiningu með því að innleiða eftirfarandi athuganir í appinu sínu fyrir iOS tæki:
1. Finndu notkun takmarkaðra API. 2. Leitaðu að jailbreak klipum eins og mods. 3. Leitaðu að óopinberum app verslunum, td athugaðu fyrir Cydia App Store undirskrift. 4. Leitaðu að kjarnabreytingum. 5. Athugaðu hvort gagnrýninn sé heill file kerfi. 6. Notaðu söfn frá þriðja aðila sem eru hönnuð til að greina tæki tampering.
Ofangreind eru bara nokkur examples um bestu starfsvenjur athuganir sem iðnaðurinn notar. Eftir því sem vistkerfi fartækja þróast geta þessar athuganir orðið úreltar. Sem slíkir ættu verktaki að fylgjast með nýjustu bestu starfsvenjum iðnaðarins til að innleiða flóttabrot eða rótgreiningu.
39
Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 319-320, 5069,
518-519. · Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 50. · ENISA Smartphone Secure Development Guidelines (2016), bls. 11, 23.
9 https://github.com/crazykid95/Backup-Mobile-Security-Report/blob/master/Jailbreak-Root-DetectionEvasion-Study-on-iOS-and-Android.pdf
40
VIÐDRÆÐI-BP03
Stjórna
Forritið útfærir keppinautaskynjun.
Lýsing
Hermir eru hugbúnaður sem notaður er til að prófa farsímaforrit með því að leyfa notanda að prófa farsímaforrit á ýmsum hermdum farsímaútgáfum og tækjum. Þó að þau séu gagnleg til prófunar ættu forrit ekki að leyfa sér að vera sett upp á hermi utan þróunarumhverfisins.
Með því að innleiða uppgötvun eftirlíkingar geta forritarar komið í veg fyrir að illgjarnir leikarar geti keyrt kraftmikla greiningu, rætur, kembiforrit, tækjabúnað, króka- og fuzzprófanir á líkt tæki sem þeir geta stjórnað. Með því að gera það geta forritarar komið í veg fyrir að illgjarnir leikarar uppgötvi veikleika innan appsins til að misnota.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að innleiða eftirfarandi uppgötvunarstefnu til að bera kennsl á eiginleika fyrir algengar hermilausnir. Nokkrar ráðleggingar um hluti til að athuga eru:
· Athugaðu rafhlöðunotkun. · Athugaðu tímasetningaramps og klukkur. · Athugaðu margsnertihegðun. · Athugaðu minni og frammistöðugreiningu. · Framkvæma netathuganir. · Athugaðu hvort það sé byggt á vélbúnaði. · Athugaðu á hverju stýrikerfið byggist. · Athugaðu hvort fingraför tækisins séu. · Athugaðu byggingarstillingar. · Athugaðu hvort keppinautar og forrit séu til staðar.
Ofangreind eru bara nokkur examples um bestu starfsvenjur athuganir sem iðnaðurinn notar. Eftir því sem vistkerfi fartækja þróast geta þessar athuganir orðið úreltar. Sem slíkir ættu verktaki að fylgjast með nýjustu bestu starfsvenjum iðnaðarins til að innleiða keppinautaskynjun. Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 31-32. · OWASP öryggisprófunarleiðbeiningar fyrir farsímaforrit (MASTG) v1.7.0 (2023), bls. 325, 521.
41
VIÐDRÆÐI-BP04
Stjórna
Forritið útfærir uppgötvun gegn spilliforritum.
Lýsing
Spilliforrit eru í auknum mæli notuð af illgjarnum aðilum sem vektor til að koma í veg fyrir fartæki notenda þar sem slík tæki veita notendum þau þægindi sem þarf til að framkvæma dagleg viðskipti. Spilliforrit nota fyrst og fremst hliðhleðslueiginleika sem rás til að fá notendur til að setja upp spilliforrit á tækjum sínum.
Með því að innleiða uppgötvunargetu gegn spilliforritum á forriti á keyrslutíma, geta verktaki komið í veg fyrir að notendur séu misnotaðir með spilliforritum sem nýta sér veikleika forrita og stýrikerfisveikleika, stela skilríkjum, taka yfir tækið og framkvæma sviksamleg viðskipti.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að innleiða greiningargetu gegn spilliforritum í öppum sínum. Þetta er hægt að gera á ýmsa vegu, en takmarkast ekki við:
· Settu Runtime-Application-Self-Protection (RASP) hugbúnaðarþróunarsett (SDK) inn í forritin sín.
· Notaðu RASP SDK til að athuga og greina fyrir spilliforrit á keyrslutíma. · Athugaðu og komdu í veg fyrir yfirlögn. · Koma í veg fyrir smelli. · Koma í veg fyrir að appminni tengist.
Ofangreind eru bara nokkur examples um bestu starfsvenjur athuganir sem iðnaðurinn notar. Eftir því sem vistkerfi fartækja þróast geta þessar athuganir orðið úreltar. Sem slíkir ættu verktaki að fylgjast með nýjustu bestu starfsvenjum iðnaðarins til að innleiða uppgötvun gegn spilliforritum.
Atriði sem þarf að hafa í huga
Ef einhvers konar illgirni greinist ættu verktaki að slökkva á forritinu og veita notandanum nauðsynlegar upplýsingar um hvers vegna forritið hefur verið óvirkt og hvetja notandann til að fjarlægja skaðlega forritið/-öppin á tækinu sínu.
Að öðrum kosti ættu verktaki að vara notandann við og slökkva á áhættuaðgerðum í forritinu þar til notandinn lagar illgjarna forritin/öppin. Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 31. · MAS Technology Risk Management Guidelines (2021), bls. 40, 49. · ENISA leiðbeiningar um örugga þróun snjallsíma (2016), bls. 23.
42
VIÐDRÆÐI-BP05
Stjórna
Forritið útfærir krókavörn.
Lýsing
Hooking vísar til tækni sem árásarmenn nota til að stöðva eða breyta hegðun farsímaforrits á keyrslutíma. Þetta felur í sér að setja inn eða krækja í framkvæmdarflæði apps til að annað hvort fylgjast með starfsemi þess, breyta hegðun þess, sprauta inn illgjarn kóða eða breyta núverandi kóðaaðgerðum til að nýta veikleika.
Með því að innleiða krókavörn í forritum geta verktaki komið í veg fyrir að ofangreindar árásir gerist og komið í veg fyrir óviðkomandi aðgang, verndað áhættuviðskipti, greint og komið í veg fyriramptilraunir til að breyta og breyta, varðveita hugverk og viðhalda áreiðanleika appsins.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að innleiða eftirfarandi tdampLeiðbeinir til að draga úr krókaárásum:
· Innleiða varnir til að loka fyrir inndælingar kóða. · Innleiða vernd til að koma í veg fyrir tengingu við aðferð með því að koma í veg fyrir breytingar á appinu
frumkóða (bæði á biðlara og þjóni). · Innleiða vernd til að koma í veg fyrir framkvæmd breyttra kóða í forritinu þínu. · Innleiða vernd til að koma í veg fyrir minnisaðgang og minnisnotkun fyrir forritið þitt. · Innleiða tamper ónæm reiknirit eða andstæðingur-tampering SDK (almennt þekkt sem
Runtime-Application-Self-Protection SDKs). · Athugaðu hvort færibreytur séu óöruggar eins og úrelt API og færibreytur.
Ofangreind eru bara nokkur examples um bestu starfsvenjur athuganir sem iðnaðurinn notar. Eftir því sem vistkerfi fartækja þróast geta þessar athuganir orðið úreltar. Sem slíkir ættu verktaki að fylgjast með nýjustu bestu starfsvenjum iðnaðarins til að innleiða krókavörn. Athugasemdir Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin/skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 135-140, 189,
318-319, 339-340, 390, 520. · MAS Technology Risk Management Guidelines (2021), bls. 56. · ENISA Smartphone Secure Development Guidelines (2016), bls. 23, 26.
43
VIÐDRÆÐI-BP06
Stjórna
Forritið útfærir yfirborð, fjarstýrt viewing og mótvægisaðgerðir á skjámyndum.
Lýsing
Hægt er að fanga eða taka upp viðkvæmar upplýsingar án skýrs samþykkis notandans þegar app er með skjáupptöku, skjámynd eða yfirborðsvirkni. Til dæmisample:
· Yfirlagsárásir blekkja notendur með því að búa til falsað lag sem líkir eftir traustum öppum, sem miðar að því að stela viðkvæmum gögnum.
· Fjarlægur viewÁrásir fela í sér óheimilan aðgang að skjá tækis, sem gerir árásarmönnum kleift að safna viðkvæmum gögnum úr fjarska.
· Skjámyndaárásir eiga sér stað þegar illgjarnir leikarar fanga skjá tækis án samþykkis notanda og draga út viðkvæm gögn.
Innleiðing á yfirborði, fjarstýring viewmótvægisaðgerðir og skjámyndir geta tryggt að viðkvæmar upplýsingar séu áfram öruggar, friðhelgi notenda sé gætt og viðkvæm gögn vernduð gegn óviljandi tapi eða misnotkun.
Leiðbeiningar um framkvæmd
Hönnuðir ættu að innleiða andstæðingur-tampathugun á eyðingu og spilliforritum í gegnum RASP SDK til að koma í veg fyrir að illgjarn forrit noti yfirlög og fjarstýringu viewing hetjudáð.
Fyrir skjámyndir geta forritarar notað FLAG_SECURE fánann fyrir Android forrit og svipaða fána fyrir iOS til að útiloka alla skjámyndarmöguleika þegar forritið er notað. Hins vegar, gerðu ráð fyrir að viðskiptaaðgerðir krefjist skjámyndagetu (td að taka skjáskot af lokinni PayNow færslu). Í því tilviki er mælt með því að slökkva á skjámyndagetu fyrir skjái eða síður sem innihalda viðkvæm gögn (PII og Authentication Data).
Hönnuðir geta einnig íhugað að fela inntak með viðkvæmum gögnum og skynjaraskjám þegar forritið er í bakgrunni.
Atriði sem þarf að hafa í huga
Sumt fyrrvampLesefni um hvar á að slökkva á þessum skjámyndagetum eru meðal annars en takmarkast ekki við: Innskráningarsíður, fjölþátta auðkenningarsíður, öryggisskilríki og síður sem breyta PII o.s.frv.
Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 166-168, 257,
259, 265-267, 366, 480-481. · Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 56. · ENISA Smartphone Secure Development Guidelines (2016), bls. 8.
44
VIÐDRÆÐI-BP07
Stjórna
Forritið útfærir ásláttarvörn eða lyklaforrit gegn sýndarlyklaborðum þriðja aðila.
Lýsing
Taka ásláttur og lyklaskráning eru aðferðir sem illgjarnir leikarar nota til að fylgjast með, skrá og skrá takkana sem ýtt er á á lyklaborði án vitundar og samþykkis notandans. Þetta gerir kleift að skrá og fanga hugsanlega viðkvæm gögn (þ.e. PII og auðkenningargögn).
Með því að innleiða mótvægisaðgerðir vegna ásláttar og lyklaskráningar geta verktaki komið í veg fyrir óþarfa tap á viðkvæmum gögnum. Nánar tiltekið miðar þessi stjórn á Android tækjum þar sem hægt er að breyta innfæddu lyklaborði Android tækja. Slíkar breytingar geta útsett öpp fyrir öryggisgöllum þar sem áreiðanleg leið milli inntaks lyklaborðs og forrita hefur ótrausta aðila á milli sín.
Leiðbeiningar um framkvæmd
Hönnuðir ættu ekki að leyfa óörugg sýndarlyklaborð frá þriðja aðila að vera notuð fyrir inntak sem geta innihaldið viðkvæm gögn. Öruggt sérsniðið lyklaborð í forriti er æskilegt fyrir slík inntak.
Með því að innleiða lyklaborð í forriti geta forritarar stjórnað því hvert skráningargögnin fara og dregið úr hættu á að óörugg sýndarlyklaborð þriðja aðila virki sem lyklaskrártæki til að fanga áslátt.
Samhliða því að nota lyklaborð í forriti ættu verktaki að innleiða eftirfarandi tillögur um inntak sem krefjast viðkvæmra gagna (þ.e. PII og auðkenningargögn): Slökkva á sjálfvirkri leiðréttingu, sjálfvirkri útfyllingu, sjálfvirkri uppástungu, klippa, afrita og líma fyrir aðgerðir/eða forrit sem innihalda viðkvæm gögn .
Athugasemdir Sumir tdampLest af aðgerðum sem ættu að nota lyklaborð í forriti eru meðal annars en takmarkast ekki við innskráningu, innskráningu á OTP eða aðra staðfestingarþætti osfrv.
Þessi öryggisstýring og bestu starfsvenjur miða fyrst og fremst að Android tækjum. Meginmarkmiðið er að tryggja öryggi hinnar traustu leiðar. Þar sem Android býður ekki upp á aðferð til að framfylgja notkun innfæddra/traustra lyklaborða, ættu verktaki að innleiða lyklaborð í forriti til að tryggja að óörugg sýndarlyklaborð þriðja aðila skrái ekki upplýsingar.
Innleiðing á öruggu lyklaborði í forriti dregur ekki úr áhættu sem tengist tæki sem er í hættu.
Þetta öryggiseftirlit er vísað til í öðrum stöðlum. Vinsamlegast skoðaðu skjölin sem eru í:
· OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 (2023), bls. 31. · OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 (2023), bls. 203, 214-215,
257, 259, 400, 414-415. · Leiðbeiningar um áhættustjórnun MAS tækni (2021), bls. 56. · ENISA Smartphone Secure Development Guidelines (2016), bls. 08, 23.
45
Heimildir
S/N 1
2
3
4
5
6 7
Skjal OWASP Mobile Application Security Verification Standard (MASVS) v2.0.0 OWASP Mobile Application Security Testing Guide (MASTG) v1.7.0 MAS tækni áhættustýringarleiðbeiningar, PCI Mobile Payment Concept Security Guidelines v2.0.0 ENISA snjallsíma leiðbeiningar um örugga þróun Android forritara Apple Developer Documentation
Heimild OWASP
OWASP
MAS
PCI-DSS
ENISA
Android Apple
Dagsett 2023
2023
2021
2017
2016
2024 2024
46
Skjöl / auðlindir
 |
CSA Safe Standard App [pdfNotendahandbók Safe Standard App, Safe Standard, App |
